bigarrow Lets Your AI Agent Point at the Screen and Leaves the Click to You

A tiny macOS CLI for Claude Code and Codex draws a giant arrow where the agent wants you to click. It's a smart answer to computer use, as long as you know who holds the permissions and who is really deciding.

Most computer-use agents are racing to click for you. One of Friday's most-discussed repos goes the other way on purpose: it can't click at all.

big-arrow-on-the-screen installs a command called bigarrow, which its README describes as "a macOS command-line tool, plus a skill for Claude Code and Codex." The agent calls it, and a big arrow with a sign appears over whatever window it's talking about. Clicks pass through the overlay, keyboard focus stays where it was, and the arrow removes itself. The README is direct about the limit: it "never clicks, types or captures. It only points."

It hit more than 300 points on Hacker News on October 9, the same day its author tagged v0.4.5. It's MIT licensed (the LICENSE file reads "Copyright (c) 2026 Franz Enzenhofer"), a single Swift binary, and the README says there's no account, no telemetry and no AI inside.

That design choice is an argument about where an agent should stop. Most of the time I think it's the right one. But it moves the safety question onto two things people tend to skip: what the human does when the arrow appears, and which app actually holds the permissions.

Why pointing is a better default than clicking

Coding agents hit a wall the moment a task leaves the terminal. A system settings pane, an OAuth consent screen, a macOS permission prompt, a button in some vendor dashboard. The agent knows what needs to happen and can't reach it, so it writes a paragraph: "Open System Settings, go to Privacy & Security, scroll to..." You squint, hunt, and click the wrong thing.

bigarrow turns that paragraph into a gesture. The agent runs something like bigarrow point --element "Allow" and you see exactly which control it means. The README's command set is small:

point aims at a target and removes the arrow after 8 seconds by default. Targets include --element, --at X,Y, --rect, --mouse, --window, --app and --peekaboo.
start draws an arrow and returns immediately, for up to 300 seconds by default. stop removes it, and stop --all clears everything.
elements --app X lists the labels --element can match.
doctor reports permissions and displays.
Every command takes --json, and --dry-run --json reports where the arrow would land without drawing it.

The exit codes are agent-friendly too: 0 for success, 2 for bad input, 3 when the target isn't found, and 4 when a permission is missing. That last one names the app and the settings pane, so the agent can tell you what to fix instead of guessing.

Compare that with full computer use. An agent that clicks needs screen capture to see, input control to act, and enough judgment to know when not to. bigarrow needs none of that to draw. The worst it can do is point at the wrong thing.

The click is now the approval step

Here's the catch, and one Hacker News commenter put it sharply: "If you're just there to click sudo buttons for the bot, you might as well give it root access and be done."

That's not a knock on the tool. It's a description of what the tool makes you. When the agent can only point, your click becomes the approval step for whatever the agent wanted. That's a stronger boundary than an auto-approve setting, but only if you read what you're approving. An arrow that says "click here" over an "Allow" button invites exactly the reflex that permission dialogs exist to interrupt.

Another commenter asked whether the real fix is for dialogs to grab focus on their own. Maybe. But the arrow solves a different problem: it tells you which of six similar controls the agent means. The question is whether you treat it as a pointer or as an instruction.

The author's one comment in the thread adds context worth knowing. He says that in his own testing on his Mac, Claude refused some actions, such as entering passwords, changing security settings and creating accounts on outside services, even in a permissive mode. That's one person's observation, not a guarantee, and it's about the model, not about bigarrow. It does show the intended shape: the agent narrates and points, the human handles the sensitive part.

Who actually holds the permissions

This is the part I'd want every user to read before installing.

Drawing an arrow needs no permission. Pointing at coordinates, a rectangle, the mouse, or a whole app window by name needs none either. The smarter targeting does. Per the README, --element, elements, --until-click and --app App:title need Accessibility. --window App:title needs Screen Recording plus Accessibility, unless you pass --no-raise.

And those permissions go "to the app that started bigarrow," such as Terminal, iTerm2, Ghostty, VS Code or Claude, "and not to bigarrow itself."

That's how macOS works for command-line tools, and the README is honest about it. But think about what it means in an agent setup. To let your agent point at buttons by label, you grant Accessibility to your terminal or editor. Your coding agent runs inside that terminal. So does every script and tool the agent launches. The permission you granted so an arrow could find a button is now held by the app that runs everything else.

bigarrow didn't create that exposure. Plenty of developers already granted their terminal Accessibility years ago and forgot. But a tool that encourages agents to ask for it is a good moment to check what your terminal already holds.

Put this into practice

Start with the zero-permission path. It covers more than you'd expect.

Install and test without granting anything. The README's route is brew install franzenzenhofer/tap/bigarrow, then bigarrow install-skill, which writes the skill to ~/.claude/skills for Claude Code and ~/.agents/skills for Codex. Run bigarrow doctor and see what's missing. Then try --window App and --at X,Y targets, which need no permission at all.

Add the cleanup hook. The README suggests bigarrow stop --hook as a Claude Code UserPromptSubmit hook, which clears a session's arrows when you reply. Stale arrows over the wrong window are worse than none.

Grant Accessibility on purpose, not by reflex. If you want --element targeting, consider granting it to a separate terminal app you use only for agent sessions, so your daily terminal doesn't carry it. Check System Settings, Privacy & Security, Accessibility, and remove anything you don't recognize while you're there.

Know the browser gap. In Chrome, --element needs --force-renderer-accessibility or VoiceOver; otherwise you point at page coordinates. That matters if most of your "go click this" moments happen in web dashboards.

Make a reading rule. Decide now that when the arrow lands on anything that grants access, installs, deletes or pays, you read the full dialog before clicking. Say it out loud the first few times. It sounds silly. It's the whole security model.

Honest limitations

It's macOS only. Building from source needs Xcode 16+ and macOS 14+, and CI runs on macOS 15. Windows and Linux users get nothing here.

The project is young and fast-moving. v0.4.5 shipped the same day it trended, and a small repo with a few hundred stars can change its flags quickly. Pin a version if you script against --json.

Some README claims I couldn't verify, including the line that it also passed on newer macOS releases. I'd treat those as the author's report.

--element depends on Accessibility labels, which many apps label badly or not at all. When the label isn't there, the agent falls back to coordinates, and coordinates drift with window size and display.

And pointing doesn't fix judgment. If the agent is wrong about which button to press, bigarrow makes the wrong answer very clear and very easy to click.

The arrow points both ways

bigarrow is the most honest computer-use design I've seen this month because it refuses the hard part and hands it back to you. That's a feature. It also means the boundary is you, your attention and whatever permissions your terminal already carries.

Install it, start with the no-permission targets, and audit your Accessibility list before you add anything to it. Then watch your own clicks for a week. If you catch yourself approving arrows without reading them, the tool is telling you something about your setup that no README can.

Sources: franzenzenhofer/big-arrow-on-the-screen README, Hacker News discussion, v0.4.5 release.

Medium metadata

Title: bigarrow Lets Your AI Agent Point at the Screen and Leaves the Click to You
Subtitle: A tiny macOS CLI for Claude Code and Codex draws a giant arrow where the agent wants you to click. It's a smart answer to computer use, as long as you know who holds the permissions and who is really deciding.
Tags: AI Agents, Claude Code, macOS, Developer Tools, Cybersecurity
Canonical URL: set to the fervorai.dev post on import