fix(tui): skip re-entering plan mode on resume and scope startup flags to startup#692
Merged
Merged
Conversation
…s to startup Resuming a session that was already in plan mode with --plan crashed with "Already in plan mode": the resume path called setPlanMode(true) unconditionally while session replay had already restored the active plan state. Check the session status first and only enable plan mode when it is not active yet, in both the resume startup path and the startup session picker. The /sessions picker shared the same onSelect callback, so startup flags were also re-applied on every mid-session switch, overriding the picked session's own persisted modes. Gate the flag application behind an applyStartupModes option that only the startup picker enables, and surface post-switch setup errors instead of leaving them as unhandled rejections.
🦋 Changeset detectedLatest commit: 85b10e5 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related Issue
N/A — follow-up to #683.
Problem
Two issues with how #683 applies
--auto/--yolo/--planto resumed sessions:--plancrashed at startup witherror: Internal error / Already in plan mode. Session replay restores the active plan state, and the resume path then calledsetPlanMode(true)unconditionally;PlanMode.enter()throws when plan mode is already active./sessionspicker sharesmountSessionPickerwith the startup picker, so the startup flags were also re-applied on every mid-session switch, overriding the picked session's own persisted modes (e.g. plan mode toggled off interactively got forced back on).What changed
applyStartupModesToResumedSession(): applies--auto/--yolo(idempotent on the core side), and for--planchecksgetStatus().planModefirst, only callingsetPlanMode(true)when plan mode is not active yet. This follows the existing guard-before-enter pattern (EnterPlanModeToolchecksplanMode.isActive;/newpassesplanModeviacreateSession). Used by both the resume startup path and the startup picker.mountSessionPickernow takes an options object with anapplyStartupModesswitch: only the startup picker (bare--session) enables it;/sessionsswitches keep the picked session's own persisted modes, with the footer synced fromgetStatus().onSelectpromise chain now surfaces post-switch setup failures viashowErrorinstead of leaving them as unhandled rejections.setPermissionandsetModelare idempotent and need no guard.Checklist
gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.