[Bug]: OpenCode Auto mode ignores user opencode permission patterns and asks for every bash, MCP, and webfetch call

I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.

Area: apps/server

Steps to reproduce

Run T3 Code with the OpenCode provider (opencode 1.18.30, runtime build sha256-02c38816, WSL2 runtime) and keep the thread runtime mode on Auto.
Define fine-grained permissions in ~/.config/opencode/opencode.jsonc, for example: "permission": { "bash": { "*": "allow", "rm -rf *": "ask", "git push *": "ask", "kubectl delete *": "ask" } }.
Send a turn that runs ls, then a turn that calls any MCP tool (I used context7 query-docs), then one that fetches a URL.
All three stop on the approval dialog (Allow once / Allow for workspace / Deny).

Expected behavior

Auto mode for the OpenCode provider should honor the permission configuration opencode already supports. With the config above, ls and the MCP call run without approval and git push asks. Auto then becomes the fine-grained middle ground between Supervised and Full access, instead of a second Supervised.

Actual behavior

The OpenCode adapter injects its own rule set on every session.create/session.update and overrides the user's config. buildOpenCodePermissionRules("auto") returns *: * -> ask, then allow-lists read (with .env ask), glob, grep, lsp, skill, todowrite, question, and leaves bash, edit, webfetch, websearch, codesearch, external_directory, and doom_loop on ask. MCP tools match the catch-all, so every MCP call asks. The patterns the user wrote in opencode.jsonc never reach opencode.

Findings

The installed server bundle (apps/server/dist/bin.mjs, runtime dir sha256-02c38816d0b6722af4ec74c48982ab009586fe7f84274cc757fe8f039c4784db) carries buildOpenCodePermissionRules(runtimeMode) as a binary branch on full-access. Every non-full-access mode shares one rule list; only edit flips to allow under auto-accept-edits.
The adapter applies the list at session.create({ ..., permission: buildOpenCodePermissionRules(input.runtimeMode) }), and again at session.update({ sessionID, permission: ... }) on resume and fork, so the override survives session reuse.
The Claude driver maps the same thread mode onto Claude Code's own policy: auto -> --permission-mode auto, auto-accept-edits -> acceptEdits, full-access -> bypassPermissions. I verified both behaviors in the same session pair: the identical ls, MCP call, and webfetch ran without any approval under the Claude provider in Auto mode and each prompted under the OpenCode provider in Auto mode. One mode label, two policies.
Full access is the only escape, and it removes gating entirely: *: allow, external_directory: allow, plus auto-reply to any residual ask. That is too coarse for day-to-day work, so people either approve constantly or run ungated.

Validation

sqlite3 (read-only) on ~/.t3/userdata/state.sqlite reports runtime_mode = 'auto' for the affected threads, and the T3 server process env contains none of the opencode permission config, so the injected rules are the only permissions opencode sees.
I extracted and quoted the rule list above from the running bundle rather than from docs or memory.
I reproduced the prompts listed in the repro steps on this thread before writing this report.
The OpenCode provider session receives the rules via the SDK permission field, which is why the global ~/.config/opencode/opencode.jsonc permission block has no effect under T3 while working as documented when running opencode standalone.

Suggested fix

session.create/session.update already accept permission rule arrays, and opencode already evaluates per-tool glob patterns with last-match-wins. When the runtime mode is Auto, pass the user's opencode permission config through to the session instead of the catch-all ask list, and fall back to the current defaults when no user config exists. This keeps Supervised as-is, keeps full access for people who want zero gates, and gives Auto an actual middle ground.

References

bug(opencode): Supervised, Auto-accept edits, and Auto modes collapse into blanket 'ask' for all permissions #5164 reported this collapse and closed as completed with no comment when fix(server): honor auto-accept edits for the OpenCode provider #7100 merged. fix(server): honor auto-accept edits for the OpenCode provider #7100 fixed auto-accept-edits only; Auto still collapses to ask-all in the current build.
fix(server): full-access OpenCode threads no longer ask for approvals #9282 fixed the full-access auto-reply path.
[Bug]: Changing runtime mode mid-turn hangs ProviderCommandReactor; all new sessions stay Connecting or show no status #6517 tracks the mid-turn mode-change restart that applies mode changes on the next turn.

+1 on this issue, its not that good to have only ask for anything or allow all, i prefer to use a custom permissions ruleset

In the meantime I patched my local installation in the manner the fix suggests, while im evaluating if i want to use t3+opencode for local small models.

vibe coded patch script follows in case it's useful to anyone.

❯ cat patch-t3-opencode-auto.sh
#!/usr/bin/env bash

set -euo pipefail

usage() {
  cat <<'EOF'
Usage: patch-t3-opencode-auto.sh [PATH_TO_T3_BIN_MJS]

Without an argument, the script resolves the active `t3` executable and patches
its installed dist/bin.mjs file. A timestamped backup is created beside the
target before it is changed.
EOF
}

if (( $# > 1 )); then
  usage >&2
  exit 2
fi

if (( $# == 1 )); then
  target=$1
else
  t3_command=$(command -v t3 || true)
  if [[ -z "$t3_command" ]]; then
    echo "Error: t3 is not on PATH. Pass the path to its dist/bin.mjs explicitly." >&2
    exit 1
  fi
  target=$(readlink -f -- "$t3_command")
fi

if [[ ! -f "$target" ]]; then
  echo "Error: target is not a regular file: $target" >&2
  exit 1
fi

if [[ ! -w "$target" ]]; then
  echo "Error: target is not writable: $target" >&2
  exit 1
fi

function_line='function buildOpenCodePermissionRules(runtimeMode) {'
full_access_line=$'\tif (runtimeMode === "full-access") return [{'
inherit_line=$'\tif (runtimeMode === "auto") return [];'

if grep -Fqx "$inherit_line" "$target"; then
  echo "Already patched: $target"
  exit 0
fi

function_count=$(grep -Fxc "$function_line" "$target" || true)
full_access_count=$(grep -Fxc "$full_access_line" "$target" || true)
if [[ "$function_count" != 1 || "$full_access_count" != 1 ]]; then
  echo "Error: this T3 build does not contain the expected permission function." >&2
  echo "No backup or modification was made." >&2
  exit 1
fi

timestamp=$(date -u +%Y%m%dT%H%M%SZ)
backup="${target}.backup-${timestamp}"
suffix=0
while [[ -e "$backup" ]]; do
  suffix=$((suffix + 1))
  backup="${target}.backup-${timestamp}-${suffix}"
done

cp -p -- "$target" "$backup"

target_dir=$(dirname -- "$target")
temp_file=$(mktemp --tmpdir="$target_dir" '.t3-bin.mjs.patch.XXXXXX')
cleanup() {
  [[ -z "${temp_file:-}" ]] || rm -f -- "$temp_file"
}
trap cleanup EXIT

awk -v function_line="$function_line" -v inherit_line="$inherit_line" '
  $0 == function_line {
    print
    print inherit_line
    inserted++
    next
  }
  { print }
  END {
    if (inserted != 1) exit 42
  }
' "$target" >"$temp_file"

if [[ $(grep -Fxc "$inherit_line" "$temp_file" || true) != 1 ]]; then
  echo "Error: patched output failed verification; original remains unchanged." >&2
  echo "Backup retained at: $backup" >&2
  exit 1
fi

chmod --reference="$target" "$temp_file"
mv -- "$temp_file" "$target"
temp_file=''

echo "Patched: $target"
echo "Backup:  $backup"
echo "Restart T3 Code, then select Auto for the OpenCode thread."

Actually the current setup interferes also with different agent modes. E.g. I made a readonly agent and the agent's permissions are not honored. It ended up surprising me and editing files.

Same root cause hits the opposite direction too: explicit deny entries in ~/.config/opencode (e.g. "webfetch": "deny") are silently bypassed under Full access — the injected {"*": "allow"} session ruleset wins the last-match merge, so tools the user denied run with no prompt. Agent-level permission overrides and legacy tools: false don't survive it either.

the combined effect with #12248 means that I cant start new sessions in opencode and chatgpt providers without one of them breaking

+1 to make it according to the description:

For me it is for OpenCode v2

Upgraded to nightly 0.0.46-nightly.20261011.2994, the issue is still there. The permission code is the same on main as well.

"Auto" is not very intuitive to me, it sounds like it would be something that would have AI reviewing commands and escalate only if risky.

Perhaps "System" would be more intuitive. "Use provider configuration as-is".

However the permission levels are hardcoded it seems currently. So Auto sounds like the best choice.

I forked and patched my nightly version above. Looking at how contributions work.

diff --git a/packages/provider-opencode/src/server/v2/adapter.ts b/packages/provider-opencode/src/server/v2/adapter.ts
index 785bf1a06e..1effdda62e 100644
--- a/packages/provider-opencode/src/server/v2/adapter.ts
+++ b/packages/provider-opencode/src/server/v2/adapter.ts
@@ -502,13 +502,15 @@ const sessionRules = (
   grants: ReadonlyArray<Rule>,
   mcpServerName: string | null,
 ): ReadonlyArray<Rule> => [
-  ...(policy.runtimeMode === "full-access"
-    ? [rule("*", "allow")]
-    : [
-        rule("shell", "ask"),
-        rule("edit", policy.runtimeMode === "auto-accept-edits" ? "allow" : "ask"),
-        rule("external_directory", "ask"),
-      ]),
+  ...(policy.runtimeMode === "auto"
+    ? []
+    : policy.runtimeMode === "full-access"
+      ? [rule("*", "allow")]
+      : [
+          rule("shell", "ask"),
+          rule("edit", policy.runtimeMode === "auto-accept-edits" ? "allow" : "ask"),
+          rule("external_directory", "ask"),
+        ]),
   ...grants,
   // Plan mode writes only its plan, which `paths` allows again. Shell and read

fix(harness): let opencode auto mode keep the user's permission patterns

Note

Claude Opus 5.5 responding on behalf of Ângelo.

Confirming the Full access side on T3 Code Nightly 0.0.46-nightly.20261014 with OpenCode 2.0.30 on Windows, and adding why it matters for unattended subagents.

~/.config/opencode/opencode.json has "*": "allow" plus deny rules for ssh *, git push*, gh *, rm -r*, edits under ~/.claude/*, and reads under ~/.ssh/*.

opencode run --auto with the same model: every one of those calls comes back Permission denied.
delegate_task to the OpenCode provider from a Full access thread: all of them run. ssh -V executes, ~/.ssh/config is read and goes to the model, and files are written into ~/.claude.

For a delegated child there is no workable mode today. Full access drops the user's deny list, and Auto or Supervised wait for approval on every shell call, including echo, so an unattended child hangs. The change proposed above, where auto returns no session rules and uses the OpenCode config as-is, would cover this case.

Adding the Pi provider as another case for per-provider runtime defaults (as suggested in #17395).

Pi has no automatic reviewer, so T3 deliberately runs Pi as Supervised when the thread is in Auto: mcpInjection.ts L298 passes auto as approval-required, and the injected extension asks before every non-read tool call unless the mode is full-access (mcpExtensionSource.ts L319).

That mapping is reasonable on its own, but with a single global defaultRuntimeMode there is no way to keep Claude and Codex on Auto (their own reviewers) while starting Pi threads in Full access. A user who wants Pi to run unattended has to switch every Pi thread by hand, or loosen every provider. Muse has the same gap (#20739), though Muse at least has an :auto-review profile Auto could map to.

Ask: an optional default runtime mode per provider instance, used for new threads and for delegates that inherit a mode the provider does not offer.

Version: 0.1.1-nightly.20261017.3238, Linux server and desktop app.

Request: support OpenCode's native prompt permission behavior in T3, so configured rules work as they do standalone, without requiring Full access.

The operator reports that standalone OpenCode handles permissions as desired, but T3 keeps asking for routine inspection commands. The supplied T3 screenshot shows a Command approval for a batch containing git worktree list, git log, git show --stat, head, and echo. This is a user report, not an independently reproduced end-to-end test. The locally installed OpenCode CLI reports v2.1.1.

prompt has not been removed. Current OpenCode source defines PermissionMode = "prompt" | "autoaccept"; --auto selects autoaccept, otherwise the TUI uses config.data.session.permissions:
https://github.com/anomalyco/opencode/blob/3b593dd5d27eeabf28be8db056178438b773e326/packages/tui/src/context/permission.tsx#L5-L14

This is rule-based permission handling, distinct from an LLM safety reviewer. OpenCode's documented rules allow routine commands to continue and reserve prompts for checks that resolve to ask:
https://opencode.ai/v2/docs/permissions

T3's current V2 adapter still injects shell: ask, edit: ask and external_directory: ask for Auto, with the edit exception only for Auto-accept edits:

t3code/packages/provider-opencode/src/server/v2/adapter.ts

Lines 388 to 405 in f7f9e21

    
           const sessionRules = ( 
        
             policy: RulesPolicy, 
        
             paths: ReadonlyArray<Rule>, 
        
             grants: ReadonlyArray<Rule>, 
        
             mcpServerName: string | null, 
        
           ): ReadonlyArray<Rule> => [ 
        
             ...(policy.runtimeMode === "full-access" 
        
               ? [rule("*", "allow")] 
        
               : [ 
        
                   rule("shell", "ask"), 
        
                   rule("edit", policy.runtimeMode === "auto-accept-edits" ? "allow" : "ask"), 
        
                   rule("external_directory", "ask"), 
        
                 ]), 
        
             ...grants, 
        
             // Plan mode writes only its plan, which `paths` allows again. Shell and read 
        
             // are never denied: the free tier refuses sessions whose rules deny them. 
        
             ...(policy.interactionMode === "plan" ? [rule("edit", "deny")] : []), 
        
             ...paths,

Requested behavior:

Offer an explicit native/provider-config permission mode, or documentably map OpenCode Auto to its native rule evaluation. Avoid presenting an unavailable automatic reviewer as if it were active.
In that mode, preserve OpenCode's configured allow/ask/deny decisions instead of replacing them with blanket ask rules. Preserve T3's necessary plan restrictions and internal MCP protections.
Surface remaining native approval requests in T3 normally.
Cover initial creation, resumed sessions and mode changes. Verify configured allowed inspection runs without a prompt, configured ask prompts, configured deny remains denied, and plan restrictions still hold.

Adding this here rather than opening a duplicate, since #18992 was explicitly consolidated into this tracker.

+1, same root cause. On the Linux AppImage desktop build, Auto on an OpenCode thread asks for approval on routine shell commands even with a global OpenCode permission config that allows them. The same config works as expected when OpenCode runs outside T3.

The fix proposed above (auto returns no session rules, so the native OpenCode config applies) is the behavior I'd expect. It is better than making auto equivalent to bypass, because Full access also overrides user deny rules, as noted earlier in this thread.

AppImage users cannot patch this locally in a durable way: the bundle is read-only and every update replaces it, so an upstream fix is the only practical option there.

In my custom build of T3 Code I removed these "asks" and now T3 Code asks exactly as opencode v2 configured. Works as a charm.

Reproduced on the desktop app, 0.1.6-nightly.20261031.3956, Windows 11, OpenCode 2.2.5, with delegate_task from a Claude thread in Auto mode.

Four delegated OpenCode children inherited auto and generated 155 approval requests: 83 commands, 38 file reads and 34 file changes. Claude Auto doesn't require this manual approval, so delegating to OpenCode turns an unattended parent into constant prompts.

Explicitly requesting runtimeMode: "full-access" on the child fails with runtime_mode_escalation_denied ("Child runtime mode full-access is broader than parent mode auto"). The only remaining route is raising the parent to Full access, which also removes its approval checks.

sessionRules in packages/provider-opencode/src/server/v2/adapter.ts still sets shell, edit and external_directory to ask for every non-full-access mode, and the shell/edit rules are unchanged on main at 80a2351f.

Repro:

Set a Claude thread to Auto.
Ask it to delegate a task to OpenCode.
Open the child thread and watch it request approval for routine commands.

Produced by Claude Opus 5.5 in Claude Code via t3 triage.

@juliusmarminge

Note

Claude Opus 5.5 commenting on behalf of Pedro.

The patch in this thread makes Auto send no session rules. Before anyone ships it, here's why it's unsafe, and a narrower fix for a maintainer to choose from.

Why OpenCode config loses

OpenCode joins the agent's config rules and the session's rules into one list, agent rules first. The last matching rule wins (permission.ts L86-L165). T3 sends its rules as session rules (sessionRules), so they override everything the user configured.

Supervised and Auto send shell: ask, edit: ask and external_directory: ask. On V2, MCP and webfetch now follow the user's config. Shell, edit and external-directory access still don't.
Full access sends *: allow. Deny checks use the same last-match lookup, so this allow also overrides the user's deny rules, as commenters reported above. OpenCode's own --auto enforces those denies.

Why sending no rules in Auto is unsafe

With no permission block, OpenCode 2.2.5's default build agent resolves to *: allow, with asks only for .env reads. I checked this with opencode debug agents. If Auto sent no session rules, it would behave almost like Full access for every user without a config, and external-directory access wouldn't ask either. It would also contradict the OpenCode docs, which say Auto has Supervised's rules because OpenCode has no approval reviewer.

Proposal

The adapter already re-applies some config rules after its own. agentPaths keeps the user's path-specific edit and external_directory allows. Two changes would extend that.

Full access. After *: allow, put the agent's deny rules back. This matches opencode --auto, where nothing prompts and configured denies still block.
Auto. After T3's asks, put back agent rules that name a specific action, such as shell: { "*": "allow", "git push *": "ask" }. The default agent's only broad rule is the catch-all *, so users without a config would see no change, and users with one would get their rules. Supervised would keep asking. One line in the OpenCode docs would say that Auto applies your OpenCode permission rules.

This has two limits. Auto would ignore a top-level "*": "allow" that a user writes, because it looks the same as the default. The OpenCode 1.x adapter (L628) still asks for everything in Auto, so it needs its own decision, even if 1.x gets only the Full access change.

The other option is to hide Auto for OpenCode, as T3 already does for Pi.

@juliusmarminge, which direction would you take? The Full access change looks like a plain bug either way. It could ship in its own PR, with cases in OpenCode2AdapterV2.test.ts.

Note

🤖 GPT-6.1 Sol responding on behalf of Raghav-56

Confirmed this also affects OpenCode subagents delegated from a Codex parent in Auto mode on 0.1.8-nightly.20261105.4218.

Setup: Windows T3 Desktop connected to a Linux ARM64 T3 background service; both T3 components on .4218; OpenCode 2.2.5.
Reproduction: keep the Codex parent in Auto, delegate to OpenCode through delegate_task, and ask the child to execute only pwd.
Four children inherited runtimeMode: "auto" and each requested shell approval. Models were OpenRouter Crouton Alpha, North Mini Code, Nemotron 3 Ultra, and Nemotron 3.5 Super VL. All completed successfully after approval.
Direct inspection of the native sessions confirmed shell: * -> ask, edit: * -> ask, and external_directory: * -> ask. There were no project permission overrides or external OpenCode server configured.

The tagged adapter's sessionRules implements this mapping. The shipped docs explicitly describe Auto as equivalent to Supervised for OpenCode. This is confirmation of the existing limitation, not a new regression. The .4234 release comparison contains only mobile message-delivery changes.

The delegated case leaves a Codex parent that has automatic approval review waiting for manual approval of routine child commands. A provider-native permission option, or clearer provider-specific mode availability, would address this without requiring Full access for the parent. Any native-rule mode should preserve configured denies and T3's plan restrictions and internal MCP protections.

Note

Claude Opus 5.5 commenting on behalf of Pedro.

One more effect of the Full access *: allow that this thread doesn't cover yet. It changes what the model is told it has, not only what it can run.

I measured this on OpenCode 2.2.7, so the v2 adapter. The build agent file denies skill, execute, subagent and question. The first request was about 48.2K characters from a Full access thread and about 22.4K from opencode run --standalone with the same agent file, where the denies apply. That is one agent file and one prompt, counted in characters, not tokens.

The reason is the order OpenCode evaluates rules in. It joins the agent's rules and the session's rules, agent first, and the last match wins. The tool snapshot, the skills listing and Code Mode are built from that same rule set. The trailing *: allow cancels each agent deny, so the denied tools and the skills listing go back into the request on every turn. Anyone who trimmed an agent to keep context small gets that cost back in Full access.

On main (f03db4fbef) both adapters still do this:

v2: sessionRules starts Full access with rule("*", "allow").
1.x: openCodePermissionRules returns { permission: "*", pattern: "*", action: "allow" }. Outside Full access, its trailing allows for question, task and skill (L637-L643) override agent denies for those three too.

Child sessions are fine on 1.x. openCodeChildPermissionRules puts the parent's rules first, so a child's own denies survive.

Sending no session rules in Full access isn't a safe fix, for the same reason as in Auto above:

Default agents ask on .env reads. On 1.x they also ask on external_directory and doom_loop. Full access would start prompting, and delegated children can't be raised above their parent's mode (see OpenCode 1.x subagents ignore Full access because the child's permission rules are applied after it starts #35246 and fix(opencode): Full access subagents start without approval prompts #35401).
On v2, mcpRules has to stay. The t3-code-* deny plus the thread's own allow keeps each thread on its own MCP tools.

Two options that avoid this:

Put the agent's denies back after *: allow. fix(opencode): honor native permission rules in OpenCode 2 #30438 does this for v2 and fix(opencode): full access keeps the selected agent's deny rules #24321 for 1.x. I haven't tested either against the measurement above, so I can't say yet whether the tool snapshot shrinks.
Replace *: allow with explicit allows for the actions that ask by default (external_directory, doom_loop, .env reads). Agent denies for skill, execute, subagent and question then win without reading the agent inventory. I haven't tried this.

Navigation Menu

Repository navigation

[Bug]: OpenCode Auto mode ignores user opencode permission patterns and asks for every bash, MCP, and webfetch call #11458

Steps to reproduce

Expected behavior

Actual behavior

Findings

Validation

Suggested fix

References

Why OpenCode config loses

Why sending no rules in Auto is unsafe

Proposal

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	const sessionRules = (
	policy: RulesPolicy,
	paths: ReadonlyArray<Rule>,
	grants: ReadonlyArray<Rule>,
	mcpServerName: string \| null,
	): ReadonlyArray<Rule> => [
	...(policy.runtimeMode === "full-access"
	? [rule("*", "allow")]
	: [
	rule("shell", "ask"),
	rule("edit", policy.runtimeMode === "auto-accept-edits" ? "allow" : "ask"),
	rule("external_directory", "ask"),
	]),
	...grants,
	// Plan mode writes only its plan, which `paths` allows again. Shell and read
	// are never denied: the free tier refuses sessions whose rules deny them.
	...(policy.interactionMode === "plan" ? [rule("edit", "deny")] : []),
	...paths,

[Bug]: OpenCode Auto mode ignores user opencode permission patterns and asks for every bash, MCP, and webfetch call #11458

Description

Steps to reproduce

Expected behavior

Actual behavior

Findings

Validation

Suggested fix

References

Activity

RiccardoCherchi commented on Sep 13, 2026

KostasKgr commented on Sep 15, 2026

KostasKgr commented on Sep 16, 2026

hariappointy commented on Sep 16, 2026

seankoji commented on Oct 11, 2026

AndreiShenets commented on Oct 12, 2026

KostasKgr commented on Oct 15, 2026

AngeloTadeucci commented on Oct 17, 2026

themonkeysagents commented on Oct 17, 2026

rkj commented on Oct 20, 2026

jeffpascoal commented on Oct 24, 2026

AndreiShenets commented on Oct 24, 2026

Punllarena commented on Oct 31, 2026

PedroNavHur commented on Oct 31, 2026

Why OpenCode config loses

Why sending no rules in Auto is unsafe

Proposal

Raghav-56 commented on Nov 5, 2026

PedroNavHur commented on Nov 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions