fix(vscode): apply /yolo and /auto while a turn is running - #25
Conversation
Typing /yolo mid-turn did nothing: the webview queues every input while streaming, and a queued command cannot run because the turn is parked on the approval prompt the user is trying to switch off. Even unqueued, the host framed the command as a turn and beginHostAction rejects it as busy. Permission commands now take a control path — a dedicated bridge method that changes the mode without turn framing, mirroring the CLI, where both commands are available while streaming. Flipping to yolo or auto also answers the approvals already on screen, since the engine asked for them before the mode changed. setPermissionMode no longer short-circuits on the cached mode; it always reconciles with the engine, so a drifted cache cannot silently report the mode as already set.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 41 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (10)
Comment |
commit: |
This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @pythoughts/pythinker-code@0.9.2 ### Patch Changes - [#25](#25) [`649ec69`](649ec69) - Let `/yolo` and `/auto` take effect in the VS Code extension while the agent is running, and auto-approve the requests already waiting on screen. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
1 participant
Related Issue
No issue filed — the problem is described below.
Problem
In the VS Code extension, typing
/yolowhile the agent is running does nothing. The command sits in the composer queue and the approval prompt keeps blocking the turn — which is precisely the moment a user reaches for it.Two independent causes:
isStreaming(chat.store.ts). A turn parked on an approval never ends, so a queued/yolocan never run. The deadlock is complete: the command that would stop the prompts is waiting for the prompts to stop.beginHostAction), which throwsALREADY_GENERATINGwhile busy.The CLI has neither problem:
/yoloand/autoareavailability: 'always'in the TUI registry and run mid-stream.What changed
/yolo,/auto, and/afktake a control path: a newsetPermissionModebridge method that changes the mode directly, with no turn framing — the same shape as the existingsetPlanMode. Every other slash command keeps queueing.approve_for_sessionfor yolo,approvefor auto), because the engine asked for them before the mode changed and would otherwise stay parked on them. This mirrors the web UI, which already auto-approves pending requests on the same transition.SessionRuntime.setPermissionModeno longer early-returns when the cached mode matches; it always reconciles against the engine. A drifted cache previously reported "already on" and never called through — a second path to the same symptom.Deliberately out of scope:
StatusUpdatestill carries no permission mode, so the webview has no persistent yolo/auto indicator. That gap is real but separate.Tests: 3 store tests (control path, pending-approval answering, ordinary messages still queue), 2 runtime tests (mid-turn change, cache-drift reconciliation), 2 bridge tests (dispatch without host action, param validation). Verified each fails against the old behavior.
pnpm testinapps/vscode: 317 passed.pnpm typecheckclean.Checklist
gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.