fix(permission): default opencli web tools to allow, matching browser and edits

[Astro-Han]

Summary

Drop the opencli_read / opencli_write "ask" permission defaults so the OpenCLI web adapters inherit the "*": "allow" baseline. Web automation now behaves the same as the browser_* tools and as file editing — all default-allow, no per-action prompt.

Why

The OpenCLI adapters were the lone web tools defaulting to ask, so every adapter call prompted the user — on every action, and again after each restart (the "always" grant is held only in memory and never written back to the DB). Meanwhile the browser_* tools already default to allow by a deliberate, documented design ruling (browser design §9: the embedded browser is local and fully visible to the user, which is the safety net), and file edits default to allow too. This change removes that one inconsistency.

The permission mechanism is unchanged: a user can still tighten any target via permission.opencli_read / permission.opencli_write / permission.browser rules (the gate is default-open, not absent), and the per-URL deny / redirect / page-move re-judge safety for the browser tools is left fully intact.

Related Issue

None.

Human Review Status

Pending

Review Focus

• The single behavior change: permission.opencli_read / permission.opencli_write now resolve to allow by default instead of ask. Confirm that policy is intended — web automation default-open, gated only by the visible embedded browser + stop button, configurable per target.
• That no other code path relied on those keys defaulting to ask (only pawwork-defaults.test.ts asserted it; updated here).

Risk Notes

Permissions/behavior change. OpenCLI web adapters — including write-access adapters that can act on third-party sites with the user's logged-in session — no longer prompt before running. The safety surface is now the visible embedded browser and the stop button, consistent with browser_*. A user can re-gate via permission.opencli_read / permission.opencli_write / permission.browser rules. No persistence, schema, migration, or platform surface was touched; this is agent-side permission policy in packages/opencode.

Skipped conditional checklist items: visible-UI item (no UI or copy changed — agent-side default only); platform item (no Electron / packaging / updater / signing / paths / OS-permission surface touched).

How To Verify

opencode typecheck (tsgo --noEmit): clean
bun test test/permission/ test/permission-agent.test.ts: 169 pass / 0 fail
bun test opencli-tools + browser-tools + registry + pawwork-defaults: 80 pass / 0 fail
pawwork-defaults.test.ts: opencli_read / opencli_write now assert action "allow"

Screenshots or Recordings

None — no visible UI or copy changed (agent-side permission default only).

Checklist

How to use this checklist:

• Tick a box by replacing [ ] with [x]. Do not edit, add, or remove items.
• The bot-applied label items can only be honestly ticked AFTER the PR is opened and the labeler / priority-triage bots have run — return to the PR description and tick them then.
• Most items are required. The few that are conditional are explicitly marked (conditional); for those, leave unticked if they truly do not apply and explain why in Risk Notes. All other items must be ticked before requesting human review.

• Type label — this PR carries exactly one of bug, enhancement, task, documentation. Type labels are author-added; the labeler bot does NOT assign them. Add the label in the GitHub UI, then tick this.
• Routing labels — this PR carries at least one of app, ui, platform, harness, ci. The labeler bot assigns these on PR open based on changed paths. Confirm the bot's choice (or override if wrong), then tick this.
• Priority label — this PR carries exactly one of P0, P1, P2, P3. The priority-triage bot suggests one on PR open. Confirm or override, then tick this.
• Human Review Status above is set to Pending, Approved by @<reviewer>, or Not required: <reason> (default is Pending; "not required" is restricted to bot-authored low-risk PRs).
• I linked the related issue, or stated in Summary why there is no issue.
• I described the review focus and any meaningful risks.
• I replaced the example block in How To Verify with the real verification steps and the key result for each.
• I did not introduce unrelated refactors, dependencies, generated files, or file changes beyond the stated scope.
• (conditional) I manually checked visible UI or copy changes when needed, with screenshots or recordings. Leave unticked only if no visible UI or copy changed.
• (conditional) I considered macOS and Windows impact for platform, packaging, updater, signing, paths, shell, or permissions changes. Leave unticked only if no platform/packaging surface was touched.
• (conditional) I called out docs, release notes, dependencies, permissions, credentials, deletion behavior, generated content, or local file changes when relevant. Leave unticked only if none of those surfaces was touched.
• I reviewed the final diff for unrelated changes and suspicious dependency changes.
• I am targeting dev, and my PR title and commit messages use Conventional Commits in English.

[coderabbitai]

Warning

Review limit reached

@Astro-Han, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 10 minutes and 15 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 32298aa5-db38-4133-84a3-d81c6fffe836

📥 Commits

Reviewing files that changed from the base of the PR and between 1639478 and 935c766.

📒 Files selected for processing (2)

• packages/opencode/src/agent/agent.ts
• packages/opencode/test/permission/pawwork-defaults.test.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/ungate-web-perms

---

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.}

[github-actions]

Suggested priority: P2 (includes non-doc, non-test paths outside the low-risk bucket).

P1/P0 are reserved for maintainer confirmation. Please relabel manually if this is a release blocker, security issue, data-loss risk, or updater/runtime failure.

[gemini-code-assist]

Code Review

This pull request changes the default permissions for opencli_read and opencli_write from "ask" to "allow", allowing them to inherit the default-allow baseline for web automation. However, a security review identified an inconsistency: opencli_ tools are mapped to the "browser" permission key when checking if they are disabled, but are evaluated as "opencli_read" or "opencli_write" during execution. This discrepancy means user-configured "browser" rules will not apply to these tools, causing them to fall back to the default-allow baseline and potentially bypassing user restrictions.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.