[StreamOfRon]

Fixes #147.

The helper retried checkAccess() with prompt:true every 10s, so a helper whose grant hadn't stuck (adhoc signature, or grant applied to the top-level app instead of the helper) re-prompted forever. This change prompts once per launch, then polls silently so a later manual grant still takes effect without restart.

Notes for reviewers:

• Diff is 10 insertions in aw_watcher_window/macos.swift only (new hasPromptedForAccess flag + early silent return in checkAccess()).
• start() retry loop untouched; AXIsProcessTrusted() predates the macOS 12 deployment target, so no compat concerns.
• Verified: make build-swift clean (no new warnings), pytest tests/ 78/78 pass.
• Behavior on helper restart (e.g. after an aw-qt restart) is one prompt again per new process — expected, not a regression.
• This stops the nagging but does not fix the underlying identity quirk (grant attaching to the top-level app rather than the helper); see [macos] Accessibility permission prompt reappears every ~10s even after granting access #147 for details.

[greptile-apps]

Confidence Score: 4/5

[Medium risk] Changes accessibility permission prompt behavior on macOS.

The PR appears safe to merge, though a one-time diagnostic would make an indefinitely waiting helper easier to diagnose.

Findings

1.  Missing access becomes invisible ▶

Summary

The Swift helper now requests Accessibility access at most once per launch, then checks trust silently on startup retries so a later Settings grant can take effect.

• This addresses repeated permission prompts while retaining the retry loop.
• The waiting state needs a one-time diagnostic when access remains missing.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Helper starts] --> B[Prompt-enabled trust check]
  B -->|Trusted| D[Start window capture]
  B -->|Not trusted| C[Wait ten seconds]
  C --> E[Silent trust check]
  E -->|Trusted| D
  E -->|Not trusted| C

Loading

_{Reviews (1) · Last reviewed commit: "fix(macos): prompt for accessibility acc..."}

[greptile-apps]

Missing access becomes invisible

If access is granted to the top-level app instead of the Swift helper, the helper remains untrusted. Every retry now checks silently, so it waits without recording windows or explaining which executable needs access. The Python permission alert runs only once at startup. A one-time diagnostic naming the helper and the required Settings action would make this state easier to resolve without bringing back repeated prompts.

Knowledge Base Used:

• macOS automation permissions
• macOS CLI capture backend

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[TimeToBuildBob]

Thanks @StreamOfRon — this is a clean, minimal fix for #147.

Read through the diff: the one-shot hasPromptedForAccess flag means the first checkAccess() call per process prompts, and every later call from start()'s 10s retry loop goes through the silent AXIsProcessTrusted() path. A later manual grant is picked up on the next poll (that API reads live TCC state), so no restart is needed. AXIsProcessTrusted() is available far below the macOS 12 target.

• Conflict surface: my fix(macos): keep foreground tracking when browser context fails #146 touches macos.swift too, but in different hunks (research/heartbeat code, ~L155 and L552+). The var additions near L155 are adjacent but not overlapping; a rebase should be trivial.
• Not verifiable from Linux: the actual TCC behaviour. Maintainer smoke test: tccutil reset Accessibility, launch the helper, confirm exactly one prompt, leave it ungranted for >30s (no second prompt), then grant in Settings and confirm tracking starts without restart.
• Greptile's P2 (silent waiting state) is addressed in fix(macos): give Swift helper a bundle identity so its permission entry is created automatically #150.

LGTM from my side; leaving the merge to a maintainer. Suggested order: #148 → #150 → #146 (see my note on #150 for why).