[Bug]: OpenCode keeps prompting for approvals after switching a running thread from Auto to Full access#20885

This is a bug on main, in the OpenCode 1.x adapter. It isn't the same issue as #11458 or #9282.

The session manager treats a changed runtime policy as a thread that needs resuming: providerThreadLoadKey in apps/server/src/orchestration-v2/ProviderSessionManager.ts includes runtimePolicy. The 1.x adapter (packages/provider-opencode/src/server/adapter.ts) only sets the session's permission rules in session.create and on fork. Its resumeThread just calls session.get, so a thread started in Auto keeps Auto's ask rules after you switch it to Full access. The 2.x adapter (packages/provider-opencode/src/server/v2/adapter.ts) rewrites the rules at the start of every turn, so this shouldn't happen on OpenCode 2.x.

#9282 fixed a different path (doom-loop and subagent asks) in the old apps/server/src/provider/Layers/OpenCodeAdapter.ts. The new orchestrator (#2829) removed that file before 0.1.0.

Open PR #15777 makes the 1.x adapter apply the selected policy on resume, which covers this case.

Workaround for now: start a new thread with Full access already selected. New sessions get Full access's allow-all rule at creation.

To confirm you're on the 1.x path, please share the output of opencode --version.

2. NoteGrok responding on behalf of Julius.

1	This is a bug on main, in the OpenCode 1.x adapter. It isn't the same issue as [#11458](https://github.com/pingdotgg/t3code/issues/11458) or [#9282](https://github.com/pingdotgg/t3code/pull/9282).
2	The session manager treats a changed runtime policy as a thread that needs resuming: `providerThreadLoadKey` in `apps/server/src/orchestration-v2/ProviderSessionManager.ts` includes `runtimePolicy`. The 1.x adapter (`packages/provider-opencode/src/server/adapter.ts`) only sets the session's permission rules in `session.create` and on fork. Its `resumeThread` just calls `session.get`, so a thread started in Auto keeps Auto's ask rules after you switch it to Full access. The 2.x adapter (`packages/provider-opencode/src/server/v2/adapter.ts`) rewrites the rules at the start of every turn, so this shouldn't happen on OpenCode 2.x.
3	[#9282](https://github.com/pingdotgg/t3code/pull/9282) fixed a different path (doom-loop and subagent asks) in the old `apps/server/src/provider/Layers/OpenCodeAdapter.ts`. The new orchestrator ([#2829](https://github.com/pingdotgg/t3code/pull/2829)) removed that file before 0.1.0.
4	Open PR [#15777](https://github.com/pingdotgg/t3code/pull/15777) makes the 1.x adapter apply the selected policy on resume, which covers this case.
5	Workaround for now: start a new thread with Full access already selected. New sessions get Full access's allow-all rule at creation.
6	To confirm you're on the 1.x path, please share the output of `opencode --version`.

I'm on OpenCode 1.19.3. So it this going to be fixed at some point in main or am I forced to migrated to v2?

I'm also experiencing this with the latest t3 v0.1.1-nightly.20261019.3348 and Opencode v2.0.32. It's completely unusable. I'm getting 5-10 approval prompts per second and there isn't even any hotkey for the approve button.

Also, the "Allow x this session" menu option seems to have no effect whatsoever. I keep selecting it, but keep getting prompted for the exact same types of commands and basic file edits.

5. I'm also experiencing this with the latest t3 v0.1.1-nightly.20261019.3348 and Opencode v2.0.32. It's completely unusable. I'm getting 5-10 approval prompts per second and there isn't even any hotkey for the approve button. Also, the "Allow x this session" menu option seems to have no effect whatsoever. I keep selecting it, but keep getting prompted for the exact same types of commands and basic file edits.

I can factually confirm this! I actually forgot to mention it.

I really like T3Code, but I think that there should be maybe a better focus on automated testing? It's a bit silly that basic features like these fail in the main branch.

Reproduced on current main (0f74ff8e3a) with the real app and OpenCode 1.18.18. A thread created in Auto returned a plan; after switching the composer to Full access, the next turn requested approval for printf hello > hello.txt, then requested approval again for cat hello.txt. A control thread created in Full access ran both without prompts.

The real CLI used a local scripted model endpoint because the public free models returned rate-limit errors. This exercises native tool execution and approvals, but does not verify OpenRouter or the reported OpenCode 2.0.32 behavior.

The selected policy reaches session.resumeThread at apps/server/src/orchestration-v2/ProviderTurnStartService.ts:692–696. In the 1.x adapter, packages/provider-opencode/src/server/adapter.ts:3061–3079 only reads the native session; it does not rewrite its permissions. The recorded sequence after switching was session.get → session.promptAsync, with no session.update; the native session still held Auto's ask rules. Rules are installed on creation and fork/rewind, not refreshed for this resume or mid-turn.

Existing open work overlaps this path: #15777, #21143, and #21982. This remains a per-adapter approval-policy decision for Julius; no permission implementation was changed during triage. OpenCode 2 has a separate rule-update path and needs separate reproduction for the later comments.

Reproduced on main 8acbefefc5 with Linux, the real web/server app, OpenCode 1.18.18, and the public opencode/big-pickle model. After planning in Auto, switching the same thread to Full access and requesting implementation produced both a file-change approval and a command approval for reading the file. A new thread created in Full access wrote and read its control file without prompts.

Reproduction recording · Runtime transcript.

The overlapping open PRs #15777, #21143, and #21982 remain intact. OpenRouter, OpenCode 2, and the Electron shell were not exercised in this reproduction.

Fix opened as #23453. Resuming a top-level OpenCode 1.x session now applies the selected runtime policy; task-child restrictions remain intact. Verified with the real Linux web/server app and OpenCode 1.18.18: after Auto planning and switching to Full access, the same native session writes and reads the file without approval requests. All 33 focused adapter tests and all 30 PR checks pass. OpenRouter, OpenCode 2, and the Electron shell were not exercised. The PR remains unmerged and requires human approval for its permissions change.

Closing: current main already covers this as of b5af4608ca. If you still see it on a build that includes that commit, reply and we'll reopen.