Big Arrow Gives Claude Code a Human Handoff on Mac
The MIT-licensed utility adds visual guidance for Claude Code and Codex while leaving clicks, credentials and approvals to people.
Listen
AI narration
9:45
0:00 / 9:45
AI SummaryGenerated from this article
Big Arrow, an MIT-licensed macOS utility, gives AI agents like Claude Code and Codex a way to visually guide users to specific interface elements without clicking or typing on their behalf. The open-source tool draws labeled arrows, boxes and rings over applications, allowing clicks to pass through to the underlying interface while the overlays disappear automatically.
The bigarrow command-line tool supports coordinate-based and accessibility-label targeting, with configurable durations and options like spoken text. Users can install it via Homebrew on macOS 14 or newer. However, visual guidance around permission prompts raises design questions: arrows should explain decisions rather than merely make acceptance more convenient, and agents must still provide balanced information about what they're requesting.
Big Arrow can put a labeled arrow over a macOS permission dialog without pressing its approval button. It gives AI agents a way to show where a person needs to act when a terminal message isn’t enough.
The open-source utility, available as the bigarrow command-line tool, includes an Agent Skill for Anthropic’s Claude Code and OpenAI’s Codex. According to the project README, it draws arrows, boxes, rings and labels over applications. Clicks pass through the overlays to the interface underneath, and the overlays disappear automatically unless configured otherwise.
Big Arrow does not click, type or capture the screen. Its role is to help an agent hand a task back to a person.
Mac users can install it now. Making an approval button easier to find, though, creates a consent question: an arrow should explain the decision, not merely make acceptance more convenient.
Install the CLI and Its Claude Code or Codex Skill
Big Arrow is MIT-licensed and requires macOS 14 or newer. For readers who already use Homebrew, the repository documents this installation sequence:
The first command installs the utility from the developer’s Homebrew tap. The second installs its skill for Claude Code and Codex, using ~/.claude/skills and ~/.agents/skills, respectively. These commands add the overlay tool and its agent instructions; they don’t replace an existing Claude Code or Codex setup.
Users with Xcode 16 or newer can also build from source:
swift build -c release
The resulting executable is at .build/release/bigarrow. The project describes the application itself as a single Swift binary, without an account, telemetry, daemon or menu-bar icon. Those are developer descriptions, not findings from an independent installation test.
Before involving an agent, try a coordinate-based marker to check the basic drawing behavior:
bigarrow point --at 760,500 \
--text "This is a visual marker" \
--duration 8
This example marks a location; it does not identify a particular button on your Mac. Change the coordinates to suit your display. The documented coordinate system uses global, top-left logical points, which don’t necessarily correspond one-for-one with physical display pixels.
Work with Zeniteq
Let’s work together
We’re open to thoughtful collaborations with teams building in AI. Explore the ways we can work together.
Coordinate-based drawing does not need to inspect an application’s controls, making it a useful starting point before exploring more advanced targeting.
Target the Control, Not Just a Place on the Screen
When the agent already knows where to point, coordinates work. Targeting by label can make the handoff more specific.
The README gives this accessibility-label example:
bigarrow point --element "Allow" \
--app "System Settings" \
--text "Review what this permission allows before deciding"
Here, --element identifies the control and --app narrows the search to an application. The label text is separate from the target, leaving room for an agent to explain what the person should review instead of simply repeating the button’s name.
The project also supports targeting rectangles, windows, application tabs and the mouse position. To inspect labels available in an application, use the documented command:
bigarrow elements --app "System Settings"
This avoids assuming every application exposes an identically named control. If the intended target cannot be found, the tool reports a failure. That failure gives the agent no reason to invent coordinates.
According to the README, targeting an application or window can bring it to the foreground. A selector such as --app "Google Chrome:Pull request" can also select a matching tab. The --no-raise option leaves window placement alone.
So “does not click or type” should not be read as “never changes what is visible.” Bringing the relevant window forward is part of the guidance experience, and users should expect it unless they disable that behavior.
For diagnostics, run:
bigarrow doctor
The documented command reports permissions, which process owns them, and display information. Drawing is permission-free, while some targeting depends on permissions. If a feature requests additional macOS access, review why it needs that access. The basic overlay’s permission-free behavior is not a blanket assurance.
Make the Handoff Temporary and Explicit
Big Arrow supports both a short-lived pointer and a marker that stays available during a longer interaction.
The point command defaults to an eight-second duration. For a longer handoff, start returns immediately and defaults to a 300-second lifetime:
bigarrow start --window "Safari:Inbox" \
--text "Review this window before continuing"
Remove the marker with:
bigarrow stop
The project also documents stop --all for removing all markers. Setting --duration 0 disables the time limit, so markers need not disappear automatically.
Additional options include an opt-in close button, spoken label text with --say, and --until-click, which ends the marker when the target is clicked. That last option observes a person’s action; it does not perform the click.
For agent use, a useful instruction is to reserve visual guidance for a specific handoff: identify the relevant control, explain the requested action, wait for the person, then remove the marker. The repository describes this pattern for step-by-step application tutorials as well as human-only approvals.
A disappearing marker is not confirmation that the task succeeded. Even after a click, it does not establish that the person understood a permission, completed authentication or approved the intended transaction. The surrounding workflow still needs an appropriate way to establish what happened.
The Tool Points, but It Does Not Supply the Agent’s Vision
The project’s proposed uses include permission prompts, two-factor authentication, CAPTCHAs, passkeys, payment confirmations and legal checkboxes. These are examples of where an agent might hand control back, not evidence that Big Arrow implements those workflows.
For authentication, the limits are clear: an arrow can show where a person should interact, but it does not enter a code, handle a passkey or solve a CAPTCHA.
Big Arrow’s accessibility targeting and coordinate inputs also do not amount to a general screen-understanding system. The README explicitly says it does not capture the screen. An agent needs another source of information to determine which control matters and whether its guidance is correct.
Click-through overlays preserve access to the underlying application, while border-only boxes and rings are designed to leave their contents visible. Those choices fit the tool’s limited role: add direction without taking ownership of the action.
They do not guarantee that an agent’s label is accurate. A confident arrow attached to the wrong control is still wrong.
A Pointer Can Help Consent or Pressure It
The Hacker News launch thread drew 243 points and 97 comments in a snapshot taken roughly five hours after posting. The figures document substantial attention within one developer forum. They do not establish broad adoption or provide an independent assessment of reliability.
Reactions were divided. Commenter hannasanarion argued that visual guidance could help people navigate poorly labeled, counterintuitive workplace software. Commenter hn8726 questioned whether overlays around permission prompts could obscure a decline option or visually misrepresent an approval control.
These are proposed uses and security concerns from commenters, not verified reports of Big Arrow causing either outcome. The supplied discussion does not establish a demonstrated consent-bypass incident.
The concern still raises a real design question. Click-through describes where an input goes, without saying whether the surrounding visual guidance is honest, balanced or sufficiently informative.
An agent-generated label saying “Click Allow” can turn a consequential permission request into an apparent housekeeping step. Better guidance identifies which application receives access, what the access permits, why it is being requested and whether the user can decline or choose another route.
The same principle applies to payment and account authorization: explain the transaction or requested access before pointing to confirmation. Keep the application’s own disclosure and alternative buttons visible. Avoid a celebratory green marker that implicitly presents approval as the only correct answer.
Big Arrow helps the agent show which window, tab or control it means. The decision remains with the human, and the agent still owes that person an explanation. A successful handoff should make the decision easier to understand, not merely easier to click.
