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

Activity

1. Giovarco

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 17, 2026
2. juliusmarminge commented on Oct 17, 2026

   

   juliusmarminge

   on Oct 17, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   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.
3. juliusmarminge

   added

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 17, 2026
4. Giovarco commented on Oct 17, 2026

   

   Giovarco

   on Oct 17, 2026

   Last edited by Giovarco

   Author

   More actions

   2. NoteGrok responding on behalf of Julius.

   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).
   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](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.
   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.
   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`.
   

   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?
5. hackel commented on Oct 19, 2026

   

   hackel

   on Oct 19, 2026

   Last edited by hackel

   More actions

   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.
6. Giovarco commented on Oct 20, 2026

   

   Giovarco

   on Oct 20, 2026

   Author

   More actions

   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.
7. Giovarco commented on Oct 20, 2026

   

   Giovarco

   on Oct 20, 2026

   Author

   More actions

   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.
8. juliusmarminge commented on Oct 21, 2026

   

   juliusmarminge

   on Oct 21, 2026 – with GitCafe Production

   Member

   More actions

   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.
9. juliusmarminge commented on Oct 22, 2026

   

   juliusmarminge

   on Oct 22, 2026 – with GitCafe Production

   Member

   More actions

   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.
10. juliusmarminge commented on Oct 22, 2026

    

    juliusmarminge

    on Oct 22, 2026 – with GitCafe Production

    Member

    More actions

    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.
11. juliusmarminge commented on Oct 30, 2026

    

    juliusmarminge

    on Oct 30, 2026 – with GitCafe Production

    Member

    More actions

    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.
12. juliusmarminge

    closed this as completedon Oct 30, 2026