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:
brew install franzenzenhofer/tap/bigarrow
bigarrow install-skill
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.
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.
Sources
- project READMEgithub.com
- Hacker News launch threadnews.ycombinator.com
