Remote control can create two simultaneously active turns in one thread

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #34034

Powered by Codex Action

A second controlled reproduction on codex-cli 0.146.0 confirms this remains present and adds process/file-descriptor evidence.

Environment: Linux x86_64, kernel 6.17.0-1021-azure; persistent Remote Control app-server plus a local codex resume <redacted-session> runner. Session/turn IDs, account/workspace IDs, endpoints, paths, prompts, and rollout contents are omitted.

Before submitting from mobile

• Six samples over 10 seconds found exactly one process with the target rollout open: the local CLI runner.
• The persistent Remote Control app-server did not have that rollout open.
• codex doctor --all --json reported overall healthy, rollout/DB parity healthy, zero duplicate rollout thread IDs, zero duplicate DB paths, and zero stale rows.

After opening the same chat in ChatGPT mobile Remote Control and sending a prompt while the CLI turn remained active

• Six samples over 10 seconds consistently found two independent process roots holding the same rollout inode: the CLI runner and the Remote Control app-server.
• Linux fdinfo decoded both handles as O_RDWR | O_APPEND | O_LARGEFILE | O_CLOEXEC.
• A second task_started appeared about 451 seconds after the first; the first had emitted neither task_complete nor turn_aborted.
• The overlap was operational, not only representational: while the remote-triggered turn collected these diagnostics, the original CLI turn applied a project patch and created a local commit.
• The sampled JSONL tail remained parseable, so no byte-level corruption was observed, but two tool-capable turns were concurrently mutating the same working state.

Doctor blind spot

During the confirmed overlap, codex doctor --all --json still reported healthy state and all duplicate/stale counts as zero. It appears to check inventory duplication rather than concurrent live rollout writers or overlapping nonterminal turns.

A useful regression invariant would be: at most one generation-bound live turn owner and one append authority per thread across app-server processes; a competing client must steer, queue, or explicitly abort/handoff before admission. Doctor should also surface concurrent write handles or overlapping nonterminal turns.

Practical workaround: attach the local TUI to the Remote Control app-server

On Codex CLI 0.146.0 (Linux), the safest topology I found is one managed app-server process with every UI attached to it, instead of running an independent codex resume process alongside Remote Control.

1. Gracefully exit any standalone TUI started with codex resume ... and let its active turn finish/abort cleanly.
2. Confirm the managed app-server is reachable:

codex app-server daemon version

1. Start the local TUI as a client of that same app-server:

codex --remote unix:// resume

To select an exact existing thread:

codex --remote unix:// resume <THREAD_ID>

Do not start a second daemon, and do not run a standalone codex resume concurrently with the Remote Control app-server.

After stopping the independent runner in my reproduction, the managed app-server was the only remaining process with a write-capable append FD on the rollout. This is an operational mitigation, not a correctness fix or formal guarantee; Remote Control is still experimental. The related managed-daemon approach is also discussed in #32793. The unix:// transport above is the Linux/macOS form; other platforms may require their platform-specific transport.

Additional Windows persisted-rollout evidence reproduces the same single-thread active-turn invariant violation, with the initiating client and transport unknown.

In one persisted thread, turn A emitted task_started at 05:50:01.324Z. Turn B then emitted task_started at 13:10:44.194Z, while A had emitted neither task_complete nor turn_aborted.

The 44m44.999s overlap was operational, not only UI state:

• During the overlap, turn A recorded 61 exec tool calls and 4 patch_apply_end events.
• Turn B recorded 65 exec tool calls and 6 patch_apply_end events.
• Records from both turns were interleaved in the same rollout and targeted the same workspace.
• Turn A completed at 13:55:29.193Z; turn B continued afterward.

The second turn's visible input contained automatic goal-continuation context rather than an ordinary user prompt, and no explicit fork was recorded. I cannot identify the initiating physical client or transport from the filtered rollout, so automatic goal continuation is a suspected admission path, not a confirmed root cause.

This shows that a second mutation-capable turn was admitted in one thread. The existing clientUserMessageId/clientId fields are useful for correlating echoed user messages, but they are not documented as request-idempotency keys or active-turn ownership fencing.

Suggested regression: hold turn A in flight, trigger goal continuation or resume for the same thread, and assert that no second task_started is admitted until A reaches a terminal state or an explicit abort/handoff completes.

<details>
<summary>Sanitized overlap evidence JSON — SHA-256 <code>6b5060d3109efac99c4b83aed8c1c50b0b9f739b030022f4d7c5e724a07e1037</code></summary>

{
  "schemaVersion": 1,
  "purpose": "Sanitized lifecycle and activity summary for two overlapping mutation-capable turns in one Codex thread",
  "verifiedAtUtc": "2026-08-06T16:05:55.0703564Z",
  "source": {
    "kind": "local persisted Codex rollout",
    "threadIdDisclosed": false,
    "turnIdsDisclosed": false,
    "rawPromptDisclosed": false,
    "workspacePathDisclosed": false,
    "fullRolloutAttachable": false,
    "fullRolloutReason": "The source contains private prompts, paths, tool inputs, and unrelated project history.",
    "boundedLineAnchors": {
      "turnAStarted": 66410,
      "turnBStarted": 71318,
      "turnACompleted": 72130
    },
    "sourceWasStillMutableAtVerification": true
  },
  "lifecycle": {
    "turnAStartedAtUtc": "2026-08-06T05:50:01.324Z",
    "turnBStartedAtUtc": "2026-08-06T13:10:44.194Z",
    "turnACompletedAtUtc": "2026-08-06T13:55:29.193Z",
    "turnATerminalEventBeforeTurnB": false,
    "overlapSeconds": 2684.999,
    "turnBContinuedAfterTurnACompleted": true
  },
  "overlapActivity": {
    "turnA": {
      "execToolCalls": 61,
      "patchApplyEndEvents": 4
    },
    "turnB": {
      "execToolCalls": 65,
      "patchApplyEndEvents": 6
    },
    "recordsInterleavedInOneRollout": true,
    "sameWorkspace": true
  },
  "turnBAdmissionContext": {
    "visibleInputClass": "automatic goal-continuation context",
    "ordinaryUserPromptAtStartObserved": false,
    "explicitForkObserved": false,
    "initiatingPhysicalClient": "unknown",
    "transport": "unknown"
  },
  "limitations": [
    "This summary establishes overlapping lifecycle and mutation activity, not the initiating client or transport.",
    "Automatic goal continuation is a suspected admission path, not a proven root cause.",
    "The two later cross-task result messages were distinct explicit sends and are not evidence that transport duplicated one request."
  ]
}

</details>

The 3 remaining hard problems in computer science: Cache invalidation, naming things, and state synchronization.

(I think enumeration finally solved the off-by-1 errors.)