fix(cua-driver): check_permissions prompts by default

[f-trycua]

Summary

• cua-driver check_permissions now raises the Accessibility + Screen Recording dialogs by default. Previously only {"prompt": true} did — the bare form (which installation.mdx, SKILL.md, and install.sh all tell users to run) was read-only, so new users saw ❌ NOT granted and had to go hunt for CuaDriver.app in System Settings.
• Apple's request APIs (AXIsProcessTrustedWithOptions(prompt:), CGRequestScreenCaptureAccess) no-op when the grant is already active, so this is safe to call repeatedly. Callers who explicitly want a quiet status check can pass {"prompt": false}.
• The CLI's in-process fallback (no daemon running) force-coerces prompt: false. Prompting from a one-shot CLI inside an IDE terminal would attribute the TCC dialog to the IDE's bundle, not CuaDriver.app — the user would grant the wrong identity. The existing stderr warning still steers them to start the daemon.

Why

Caught while walking through a fresh install: install.sh ends with "macOS raises the Accessibility + Screen Recording dialogs" — but only if the user knew to add {"prompt": true} themselves. Without that, the install flow surfaces a red ❌ and goes silent. The defaults should match what install.sh / installation.mdx promise.

Files

• Sources/CuaDriverServer/Tools/CheckPermissionsTool.swift — flip default + update tool description.
• Sources/CuaDriverCLI/CallCommand.swift — coerce prompt: false in the in-process fallback.
• docs/content/docs/cua-driver/reference/mcp-tools.mdx — update tool reference.
• Skills/cua-driver/SKILL.md — update prereqs guidance.

Test plan

• swift build clean.
• Existing test_no_daemon_emits_tcc_warning_on_stderr integration test passes (exercises the in-process path; verifies warning + summary). The other test in that file fails on a pre-existing .app-bundle path assumption unrelated to this change.
• Smoke-tested locally with the daemon running: dialog fires when a grant is missing; no dialog (and no behavior change) when both grants are already active.
• Smoke-test from a fresh-install machine where neither grant has been given to confirm the dialogs actually appear in the install flow.

🤖 Generated with Claude Code

Summary by CodeRabbit

Release Notes

• Documentation

  • Updated check_permissions tool documentation to clarify that the default behavior now triggers macOS permission dialogs for missing Accessibility/Screen Recording grants.
  • Revised permission-checking prerequisites and added guidance on using read-only status checks with {"prompt": false}.

• Changes

  • check_permissions now prompts for missing permissions by default; repeated calls are safe.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs	Building	Preview, Comment	Apr 26, 2026 6:50pm

[coderabbitai]

Caution

Review failed

Pull request was closed or merged during review

📝 Walkthrough

Walkthrough

The PR changes the check_permissions tool's default behavior to automatically prompt for macOS TCC permissions when missing, rather than requiring explicit opt-in. Documentation and CLI code are updated to reflect this inversion, with in-process execution forcing read-only checks to avoid permission dialogs in incorrect contexts.

Changes

Cohort / File(s)	Summary
Documentation Updates docs/content/docs/cua-driver/reference/mcp-tools.mdx, libs/cua-driver/Skills/cua-driver/SKILL.md	Updated tool documentation and prerequisite instructions to clarify that check_permissions now defaults to prompting for missing TCC grants. Example payloads and guidance revised to show prompt: false for read-only status checks.
Implementation Changes libs/cua-driver/Sources/CuaDriverServer/Tools/CheckPermissionsTool.swift, libs/cua-driver/Sources/CuaDriverCLI/CallCommand.swift	Tool behavior inverted from opt-in to opt-out prompting using ?? true default. CLI code now forces prompt: false when running in-process to prevent TCC dialogs in wrong security context.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• cua-driver: fix post-install permissions guidance #1368: Updates installer guidance to run the daemon during permission checking so prompts are correctly attributed to the app rather than the installer process.

Suggested reviewers

• ddupont808

Poem

🐰 Permission checks now prompt with glee,
By default showing what we need to see,
But in-process reads stay quiet and clean—
prompt: false keeps dialogs unseen!
A safer dance 'tween app and TCC. ✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: the check_permissions tool now prompts for permissions by default, which aligns with the core behavioral shift across all modified files.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/cua-driver-check-permissions-prompt-default

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}