Resuming a session can now re-enter plan mode by reading your transcript, and this is on by default.
What's wrong with this entry?
Resuming a session could previously only restore plan mode from a value the previous run recorded. A new path instead scans the transcript backwards for plan markers, ExitPlanMode tool calls and plan-mode user turns, classifies the session as still in a plan, exited, or neither, and re-enters plan mode when a plan is open and no recorded mode exists. It is controlled by the tengu_tranquil_fern gate, which defaults to on when no server value is present.
- Applies only when a
--sdk-urlis used, or when no permission mode was given on the command line; never when forking a session. - Tool results that begin with the team-lead submission message, or that carry an awaiting-leader-approval marker, count as still in plan.
- When it fires, the restore source is recorded as "transcript" rather than the previous run's recorded mode.
- A second latch condition sits alongside the gate, and what it tracks is not determinable from this code path.
[planModeResume] re-entering plan mode from the transcript's open plan segment (was
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.235
Very large plans cannot be approved
Both mention plan mode
-
v2.1.235
Plans over 200,000 characters cannot be approved
Both mention plan mode
-
v2.1.239
Resuming a session that was in plan mode puts you back in plan mode
Both mention plan mode