You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
permissions: late reply can execute a tool after session abort #54332
A pending edit permission can still be approved after its session was aborted, and the late approval can execute the write after the user pressed Stop.
Environment
OpenCode CLI/server: 1.18.32
Fresh temporary XDG profile and disposable project
Project config: edit permission set to ask
Basic-auth-protected loopback server
Native browser client using assistant-ui OpenCode runtime 0.2.29
Reproduction
Start a prompt that asks OpenCode to write a unique file; wait until the native edit permission is pending.
Click Stop in the client.
Observe POST /session/{id}/abort returns HTTP 200 with JSON true; the UI says the run was aborted.
In the observed race, the pending permission card remained available after abort. Click Allow once.
Observe POST /permission/{permissionID}/reply returns HTTP 200 with JSON true, and the requested file is created after the abort.
Observed synthetic fixture: late.txt was created with NATIVE_LATE_APPROVAL_2026 after the abort. In a second attempt, the stale Allow button disappeared and the file remained absent, so the late-write behavior appears timing-dependent. The session status endpoint reported no active session after abort. No real user project or provider profile was used. A provider key was inherited by the isolated server process from the environment for benign model-backed E2E prompts; its value was not read, printed, or recorded.
Expected behavior
Aborting a session should invalidate unresolved permission requests owned by that run. A late permission reply must fail closed and must not start or complete the pending tool call or modify the target file.
Actual behavior
In the reproduced race, abort returned true, but the server accepted a later permission reply (true) and performed the write after cancellation.
Evidence and scope
This was observed during AGENTILOGUE issue #34's disposable local E2E; detailed statuses and matrix results are in PR #36. This is separate from the title-generation bug in assistant-ui #9244. The current native lane is experimental; AGENTILOGUE #34 remains open pending its complete E2E matrix.
Thanks for the detailed report and the careful repro notes!
This was observed on OpenCode 1.18.32, which is v1. v1 now only gets fixes for critical bugs (data loss, security problems, or crashes or breakage with no workaround). Here the write only happens if you click Allow on a permission card that is still showing after the abort. It's also timing-dependent, and you can avoid it by rejecting or ignoring a card that's still showing after Stop. So this is unlikely to be fixed in v1.
We'd encourage trying v2 (@opencode/cli, the opencode command). From reading the code, v2 should handle this differently, though we haven't tested it. There the tool's wait for a permission reply is interrupted when the session is aborted, and the pending request is removed. A late reply to /permission/{id}/reply should then fail as not found, and the tool should not run.
Related issues that touch pending permissions and abort/cleanup, though none of them is this exact problem:
Not reproducible on v2 — the late approval fails closed here. (Tested with @opencode/cli 2.0.26 on Windows 10, driving an HTTP client that is allowed to ask.)
Setup: opencode serve --port 18085 with OPENCODE_CONFIG_CONTENT={"permissions":[{"action":"edit","resource":"*","effect":"ask"}]}, in a temp project directory.
POST /api/session + POST /api/session/{id}/prompt ("create a file named late.txt ...") → a pending edit permission appeared (per_...).
POST /api/session/{id}/interrupt → {"interrupted": true}.
GET /api/session/{id}/permission → []; the pending request is removed.
Late POST /api/session/{id}/permission/{requestID}/reply with {"decision":"once"} → HTTP 404.
late.txt was never created.
Mechanism in the v2 source: the tool waits inside Permission.assert on an interruptible deferred (packages/core/src/permission.ts); abort interrupts the run and Effect.ensuring removes the pending request, so a late reply resolves to Permission.NotFoundError.
Note the non-interactive opencode run path doesn't leave a pending request at all — it auto-rejects asks ("This non-interactive run cannot ask the user for permission"), so only clients that can actually prompt reach the race window, and there it now fails closed.
Closing this as not planned. The late-approval race was reported on v1 (1.18.32), where only critical fixes are made. The write needs an explicit Allow after Stop, and rejecting stale permission cards avoids it, so it doesn't meet that bar. We left the issue open for a day in case it reproduced on v2 or you saw it as critical, and we haven't heard back.
From reading the v2 code (@opencode/cli), aborting a session should cancel the pending permission wait, and a late reply should be rejected. We haven't tested this. If you can reproduce the late write on v2, please open a new issue with the v2 version and steps. Thanks again for the careful report!
Activity
opencode-agent commentedon Oct 10, 2026
Thanks for the detailed report and the careful repro notes!
This was observed on OpenCode
1.18.32, which is v1. v1 now only gets fixes for critical bugs (data loss, security problems, or crashes or breakage with no workaround). Here the write only happens if you click Allow on a permission card that is still showing after the abort. It's also timing-dependent, and you can avoid it by rejecting or ignoring a card that's still showing after Stop. So this is unlikely to be fixed in v1.We'd encourage trying v2 (
@opencode/cli, theopencodecommand). From reading the code, v2 should handle this differently, though we haven't tested it. There the tool's wait for a permission reply is interrupted when the session is aborted, and the pending request is removed. A late reply to/permission/{id}/replyshould then fail as not found, and the tool should not run.Related issues that touch pending permissions and abort/cleanup, though none of them is this exact problem:
repliedevents on permission cleanup pathsIf you can reproduce the late write on v2, or you think this should count as critical in v1, please reply here with the details.
reynold-hu commentedon Oct 10, 2026
Not reproducible on v2 — the late approval fails closed here. (Tested with
@opencode/cli2.0.26 on Windows 10, driving an HTTP client that is allowed to ask.)Setup:
opencode serve --port 18085withOPENCODE_CONFIG_CONTENT={"permissions":[{"action":"edit","resource":"*","effect":"ask"}]}, in a temp project directory.POST /api/session+POST /api/session/{id}/prompt("create a file named late.txt ...") → a pendingeditpermission appeared (per_...).POST /api/session/{id}/interrupt→{"interrupted": true}.GET /api/session/{id}/permission→[]; the pending request is removed.POST /api/session/{id}/permission/{requestID}/replywith{"decision":"once"}→ HTTP 404.late.txtwas never created.Mechanism in the v2 source: the tool waits inside
Permission.asserton an interruptible deferred (packages/core/src/permission.ts); abort interrupts the run andEffect.ensuringremoves the pending request, so a late reply resolves toPermission.NotFoundError.Note the non-interactive
opencode runpath doesn't leave a pending request at all — it auto-rejects asks ("This non-interactive run cannot ask the user for permission"), so only clients that can actually prompt reach the race window, and there it now fails closed.opencode-agent commentedon Oct 11, 2026
Closing this as not planned. The late-approval race was reported on v1 (
1.18.32), where only critical fixes are made. The write needs an explicit Allow after Stop, and rejecting stale permission cards avoids it, so it doesn't meet that bar. We left the issue open for a day in case it reproduced on v2 or you saw it as critical, and we haven't heard back.From reading the v2 code (
@opencode/cli), aborting a session should cancel the pending permission wait, and a late reply should be rejected. We haven't tested this. If you can reproduce the late write on v2, please open a new issue with the v2 version and steps. Thanks again for the careful report!