QWE AI Academy Your agent finished the refactor. You’re still hunting Allow
Drawing the overlay needs zero macOS permissions. Label lookup is what costs Accessibility – and that grant sticks to Terminal, Ghostty, VS Code, or Claude, not the bigarrow binary. Exit code 4 on day one usually means the launcher app is wrong, not a broken arrow engine.
The Show HN thread (about 368-410 points and 160+ comments within roughly a day, as reported on launch) is full of airhorn jokes. Fine. If you run Claude Code or Codex on a Mac, the useful part is quieter: the model already knows the control label, but your eyes left the terminal. Allow, 2FA, CAPTCHA, pay wall – same failure mode.
Think of it like a sticky note slapped on the real pixel, not a second UI the agent “drives.” You still click. The note just stops the scavenger hunt.
Pro tip:
bigarrow doctorbefore the first agent session. It names the app that needs Accessibility and lists displays. One fix beats mid-flow guessing.
What it is – and the hard no
big-arrow-on-the-screen (bigarrow) is an MIT Swift CLI plus a skill pack for Claude Code and Codex. README position is blunt: transparent overlay across displays and Spaces, click-through, no focus steal, no daemon, no menu bar, no account, no telemetry, no model inside. It points. It does not click, type, or capture. That refusal is the product.
Practical setup: two commands, then break exit codes on purpose
macOS 14+ with Homebrew (paths as of the project README):
brew install franzenzenhofer/tap/bigarrow
bigarrow install-skill
bigarrow doctorinstall-skill writes Agent Skills into ~/.claude/skills and ~/.agents/skills. Source build: Xcode 16+, swift build -c release, binary at .build/release/bigarrow.
- Accessibility goes to the app that spawns bigarrow – terminal or IDE – never a fictional
bigarrow.app. - Smoke test:
bigarrow point --at 400,300 --text "You are here". Default lifetime forpointis ~8s, then it’s gone. - Fail on purpose:
bigarrow point --element "NoSuchLabel" --app "Safari". Exit 3 = target missing; 4 = permission; 2 = bad input; 0 = ok. Agents parse numbers cleaner than paragraphs. - Inventory labels first:
bigarrow elements --app "Finder"before you trust--elementin a live flow.
Skill cost on the always-on description sits around ~182 tokens per the README; fuller instructions load when the agent actually points.
Advanced usage agents actually need
point is a poke (~8s). start returns immediately and holds longer (~300s default) until stop, timeout, owner process exit via CLAUDE_PID / BIGARROW_OWNER_PID, optional --close-button, or bigarrow stop --hook from your session cleanup. --duration 0 = no time cap. Crashed agent, fewer orphan overlays – that’s the owner-PID story in one line.
# Coordinates only - no Accessibility
bigarrow point --at 760,500 --text "Confirm this control" --color orange
# Copy chip on the sign ({{value}} → one-click copy)
bigarrow start --element "One-time code" --app "Google Chrome:Checkout"
--text "Paste {{otp-7f3a}} into the field" --color blue
# Hold, speak, manual close, then wipe
bigarrow start --window "Mail" --text "This window" --say --close-button
bigarrow stop --allTargeting that shows up when you run agents for real: --at X,Y, --window App[:title], --element Label --app App, plus --follow, --until-click, --dry-run --json, --png. Style flags are urgency encoding for humans, not the model.
Chrome page DOM is the sharp edge. Turns out – official FAQ, checked October 2026 – --element inside page content needs Chrome started with --force-renderer-accessibility or VoiceOver on. Electron apps generally behave. Chrome’s toolbar is fine. Coordinates always work when AX inside the page doesn’t.
How much trust do you want in a glowing arrow when the agent already has a shell? That’s the real product question; the CLI only makes the handoff visible.
Limits that still bite
macOS only. No Windows/Linux build as of this writing. It will not press the button – on purpose – so payments and auth stay human-in-the-loop. Launch-era project on the HN wave; flags move, and early write-ups saw Homebrew-tap distribution more than a long tagged-release history.
| Gotcha | What happens | What you do |
|---|---|---|
| Permission on wrong app | Exit 4; AX targets never resolve | doctor, enable Accessibility for the launcher |
| Chrome page labels | --element misses DOM |
Force renderer accessibility, or --at |
| macOS 26 window titles | --window App:title wants Screen Recording (+ Accessibility to raise unless you skip raise) |
Prefer plain app window, element, or coordinates when you can |
| Covered target | Arrow waits until the control is visible again | Let raise happen; don’t block it unless you mean to |
Pulsing arrow CPU: about 1.4% on a CI runner via Core Animation (README claim). 104 automated tests ship with the project. When an arrow lands “almost” right, elements plus --dry-run --json beats eyeballing.
FAQ
Does bigarrow work with tools other than Claude Code and Codex?
Yes. Any shell can call the CLI. The packaged skill only auto-teaches those two.
Will an agent use arrows to hide Decline and trick me?
Not beyond what shell access already allows. Overlays self-terminate on duration and owner-PID exit; the tool still doesn’t create a new privilege boundary. Treat agent shell as full trust either way.
I installed it but arrows never appear on the right display / Space
README claims coverage for multi-display, full-screen, Stage Manager, and Spaces. If nothing draws: run doctor, confirm you’re on the same Space as the raised target, then prove the pipeline with bare --at so AX isn’t the variable. Still blank after that? Re-check which app holds Accessibility – launcher mismatch is still the common exit-4 path.
Next: brew install franzenzenhofer/tap/bigarrow && bigarrow install-skill && bigarrow doctor, fix the one Accessibility checkbox it names, then tell your agent: “When you need me to click, use bigarrow and put a full sentence on the sign.”