Skip to content

Plugin: reset default mode after /codex_plan off#8

Merged
huntharo merged 2 commits intomainfrom
codex/investigate-stuck-plan-mode-status
Mar 21, 2026
Merged

Plugin: reset default mode after /codex_plan off#8
huntharo merged 2 commits intomainfrom
codex/investigate-stuck-plan-mode-status

Conversation

@huntharo
Copy link
Contributor

Summary

This fixes a stuck plan-mode handoff where /codex_plan off could report success in chat, /codex_status could show Plan mode: off, and the next normal turn could still be executed by Codex in Plan mode.

The plugin was treating "default mode" as an omitted collaborationMode field on turn/start. In the Codex app server, omitting collaborationMode does not explicitly switch the thread back to Default mode; it preserves the thread's prior collaboration mode. That let a thread remain in Plan mode after the local plugin state had already cleared.

This change:

  • sends an explicit Default collaboration-mode payload for normal turns
  • uses the resumed thread model/reasoning effort as fallback when synthesizing that payload
  • adds targeted debug logging around /codex_plan off, /codex_status, and outbound turn/start
  • documents /codex_plan off more clearly in the README

Reproduction

This is the most likely repro path based on the observed logs and chat transcript:

  1. Bind a chat to an existing Codex thread.
  2. Enter plan mode with /codex_plan <goal> and let Codex answer in Plan mode.
  3. Exit with /codex_plan off.
  4. Confirm /codex_status reports Plan mode: off.
  5. Send a normal coding request that would require execution, for example git commit or another mutating action.

Observed behavior before this change:

  • the gateway logs the new turn as mode=default
  • chat says plan mode was exited
  • the next assistant response still says it cannot act because it is "still in Plan Mode"

Expected behavior:

  • once /codex_plan off succeeds, the next turn should be started with an explicit Default collaboration mode
  • Codex should no longer refuse mutating actions on the basis that the thread is still in Plan mode

Evidence

Sanitized gateway log pattern from the failure:

[gateway] codex turn starting app-server run ... existingThread=<thread> mode=default
[gateway] codex turn attaching to shared app-server connection ... mode=default prompt="Can you try to git commit..."
[gateway] codex turn completed ... terminalStatus=completed text=yes plan=no
[gateway] codex outbound send ... preview="Not in the current mode. We’re still in Plan Mode..."

Sanitized chat sequence from the same failure:

/codex_status
Plan mode: off

/codex_plan off
Exited Codex plan mode. Future turns will use default coding mode.

Can you try to git commit the readme change?
Not in the current mode. We’re still in Plan Mode...

New logging added by this PR should make the mismatch visible:

codex plan off requested ... active=<mode> boundThread=<thread>
codex status snapshot bindingActive=yes activeRun=<mode> boundThread=<thread> threadModel=<model> threadCwd=<cwd>
codex turn thread resumed ... model=<model> reasoningEffort=<effort>
codex turn start payload ... requestedMode=default modeSource=synthesized requestedModel=<model> threadModel=<model> collaborationPayload=yes

The important check is that the outbound turn/start path now logs collaborationPayload=yes for normal post-plan turns instead of silently omitting the collaboration-mode override.

Validation

  • pnpm test
  • pnpm typecheck

@huntharo huntharo merged commit d4ecc08 into main Mar 21, 2026
4 checks passed
@huntharo huntharo deleted the codex/investigate-stuck-plan-mode-status branch March 21, 2026 01:15
@huntharo huntharo moved this from In Review to Done in OpenClaw Codex App Server Mar 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

1 participant