fix(server): honor auto-accept edits for the OpenCode provider

[Rishet11]

What Changed

On OpenCode, picking Auto-accept edits did nothing. Every file edit still stopped and waited for approval, exactly as in Supervised. The mode was selectable and had no effect.

buildOpenCodePermissionRules only branched on full-access. Everything else - approval-required, auto-accept-edits, auto - got the same blanket ruleset with edit set to ask, so three different modes behaved identically.

Edits are now pre-approved in Auto-accept edits, which is what the mode already promises.

Why

docs/user/permission-modes.md already specifies the behaviour:

Auto-accept edits: auto-approve edits, ask before other actions. File changes go through
without prompting; commands and anything else still stop for approval.

That is the documented contract, and OpenCode was not honouring it. ClaudeAdapter maps the same mode to Claude's acceptEdits, and Codex maps it onto a workspace-write sandbox, so OpenCode was the odd one out.

auto is deliberately left alone. My first draft changed it too, on the reasoning that auto sits above auto-accept-edits and should not prompt more than the mode below it. The same doc rules that out:

Auto: routine actions proceed without you; risky ones still ask. How this is enforced depends
on the provider: Codex delegates routine approvals to an AI reviewer, Claude uses its own auto
permission mode, and providers without an equivalent (such as OpenCode) fall back to asking, like
Supervised.

OpenCode falling back to Supervised for auto is documented and intended, not a bug, so this PR does not touch it.

What this does not change

This is a change that makes the app ask permission less often, so the limits are worth stating plainly:

• Only edit, and only in one mode. bash, webfetch, websearch, codesearch, external_directory, doom_loop and the * catch-all still ask, in every mode below full-access. Running a command is still gated.
• approval-required and auto are untouched. Both still ask for everything, edits included.
• full-access is untouched.

The issue also asks for a second thing - wiring the auto_review guardian subagent into OpenCode for auto mode. I have not done that, for two reasons. It is the documented fallback described above, and OpenCode's permission model is a static rule table whose SDK action type is "allow" | "deny" | "ask", with no reviewer or callback hook to wire a guardian into. Giving OpenCode an AI reviewer is a design decision for you, not something to infer from the issue.

On rule precedence

Worth spelling out, since the ruleset keeps a * catch-all set to ask and the new rule has to win against it.

The resolution happens inside the OpenCode server rather than here, and the SDK type carries no precedence documentation - PermissionRule is just { permission, pattern, action }. The existing ruleset answers it though: { permission: "question", action: "allow" } already sits after { permission: "*", action: "ask" }, and questions do get through today. If the catch-all took precedence that line would never have worked. The new edit rule is in exactly the same position, so it resolves the same way.

If that is wrong and the catch-all does win, this PR is inert rather than dangerous - the mode would keep asking, as it does now.

UI Changes

n/a - no interface change. The difference is that an OpenCode edit in Auto-accept edits no longer opens an approval prompt.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes (n/a)
• I included a video for animation/interaction changes (n/a)

Verification

vp test run apps/server/src/provider/opencodeRuntime.permissions.test.ts   #  5 passed
vp test run apps/server/src/provider/opencodeRuntime.cliParsers.test.ts    # 14 passed (unchanged)
vp run --filter @t3tools/server typecheck                                  # exit 0
vp lint / vp fmt --check on both touched files                             # clean

The new test file pins the whole table, not just the changed cell: edits allowed under auto-accept-edits, edits still asked under approval-required and under auto (the documented fallback), bash/webfetch/external_directory/* still asked, and full-access still a single allow-all rule. That last group is the one that matters for review - it fails if a future change quietly widens anything beyond edits.

Putting action: "ask" back on the edit rule fails it:

FAIL  buildOpenCodePermissionRules > pre-approves edits once the user has chosen to auto-accept them
AssertionError: Expected values to be strictly equal:
Expected: "allow"

Fixes #5164

Implemented with Claude Opus 5 via Claude Code.

---

Note

Low Risk
Narrow server-side permission mapping change with tests; only relaxes prompts for edits in one mode, leaving commands and other actions gated.

Overview
Auto-accept edits on the OpenCode provider now matches the documented behavior: file edit permissions are allow instead of prompting like Supervised.

buildOpenCodePermissionRules sets editAction to allow only when runtimeMode === "auto-accept-edits". approval-required, auto (documented Supervised fallback without an AI reviewer), and full-access are unchanged; bash, webfetch, and other permissions still ask outside full access.

New unit tests in opencodeRuntime.permissions.test.ts lock the permission table for each runtime mode.

^{Reviewed by Cursor Bugbot for commit 2a32b4a. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix buildOpenCodePermissionRules to allow edits in auto-accept-edits mode

Previously, the edit permission was hardcoded to ask in opencodeRuntime.ts regardless of runtime mode. Now, edit is set to allow when runtimeMode is auto-accept-edits, and remains ask for auto and approval-required modes.

^{Macroscope summarized 2a32b4a.}

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3b99fbb6-ad13-477a-a59e-96e264e3b00f

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

[macroscopeapp]

Approvability

Verdict: Approved 2a32b4a

This is a small, well-tested bug fix that makes the 'auto-accept-edits' runtime mode honor the user's preference. The change is a single conditional with clear intent, comprehensive test coverage, and inline documentation explaining the reasoning.

^{You can customize Macroscope's approvability policy. Learn more.}