[Feature]: Add a native Start/Resume action for Codex threads without injecting a "continue" message

[wzyhn]

Problem or use case

When a Codex-backed thread is stopped/idle and I simply want the agent to continue working, the practical workflow in T3 Code is to send a user message such as continue.

That works, but it has several drawbacks:

• it adds a synthetic user-authored message to the conversation;
• it pollutes the transcript/context with text that carries no real intent;
• it makes the T3 conversation differ from the native Codex experience;
• on mobile/remote use, it adds an unnecessary interaction just to wake the agent back up.

In the native Codex app, there is a Start-style control that can resume/start the agent without requiring me to type a fake continue message. It would be useful for T3 Code to expose equivalent provider-native behavior where the Codex app-server supports it.

T3 already persists Codex continuation state / resume cursors and uses the Codex app-server resume path, so this seems like a natural provider-specific UX improvement rather than a transcript workaround.

Proposed behavior

For a Codex-backed thread that has a resumable provider session and is not currently running, expose a Start / Resume action in the composer.

Invoking it should:

1. resume/start the existing Codex provider session using provider-native semantics where possible;
2. preserve the same Codex thread/session identity and continuation state;
3. not append a fabricated user message such as continue to the T3 or Codex transcript;
4. transition the T3 session/turn state normally so Stop, remote sync, and activity indicators continue to work;
5. fail clearly if the underlying Codex state actually requires new user input instead of silently fabricating input.

The exact app-server method should remain an implementation detail; the goal is behavioral parity with the native Codex "Start" experience, not to require a particular protocol call.

Why this matters

T3 Code is especially useful as a remote/mobile control surface for long-running Codex work. A provider-native resume button makes that workflow feel like controlling the existing agent session rather than sending meaningless chat messages to trigger it.

It also keeps the conversation history semantically clean: every user message should represent actual user intent.

Acceptance criteria

• A resumable, non-running Codex thread exposes a Start/Resume action where appropriate.
• Using it does not create a synthetic user message.
• The existing Codex conversation identity / resume cursor is preserved.
• The action does not create a second disconnected Codex thread.
• Session/turn state is reflected correctly in web/desktop and remote/mobile clients.
• Stop/cancel still works after starting through this action.
• If Codex requires fresh user input, T3 surfaces that state instead of inserting hidden or synthetic prompt text.
• Normal typed messages continue to behave exactly as they do today.

Related area

• Codex provider adapter / app-server integration
• provider session lifecycle
• web/mobile composer controls

[juliusmarminge]

Triage

Valid enhancement. Not a duplicate of nearby resume/restart threads. The Codex adapter already supports promptless continuation; clients cannot invoke it without sending a user message.

What the report is asking for

On a stopped/idle Codex thread with a resumable provider session, expose a composer Start / Resume that:

• starts a new turn on the existing Codex thread (turn/start without a fabricated prompt)
• does not append a synthetic user message such as continue
• keeps Codex session identity / resume cursor
• updates T3 session/turn state so Stop, remote sync, and activity indicators still work
• fails clearly if Codex actually needs new user input

Typed messages should keep today’s behavior.

What the code already does

Promptless continuation exists as an internal recovery path, not a user action:

• Codex declares promptlessTurnContinuation: true (apps/server/src/provider/Layers/CodexAdapter.ts).
• ProviderSendTurnInput.continuation allows an empty turn only for adapters that opt in (packages/contracts/src/provider.ts, ProviderService.sendTurn). Claude is rejected with “requires an explicit continuation prompt”.
• Codex sendTurn already omits prompt from app-server turn/start when input is empty (CodexSessionRuntime.ts). Session identity still goes through thread/resume / thread/start.
• Server restart recovery already calls sendTurn({ continuation: true }) for Codex (serverRuntimeStartup.ts). Other providers get the synthetic "Continue where you left off." prompt.
• The timeline already knows how to render a promptless restart without a new user row (MessagesTimeline.logic.ts).

What is missing

The user-facing turn path always creates a user message:

• thread.turn.start requires message: { role: "user", text } (packages/contracts/src/orchestration.ts).
• The decider emits thread.message-sent for every client turn start.
• ProviderCommandReactor.processTurnStartRequested looks up that user message and fails if it is missing.
• Web/mobile composers hide or disable send when there is no sendable content.

promptlessTurnContinuation is not advertised to clients, and OrchestrationSession does not expose resumeCursor, so the UI has no first-class “this session can Start/Resume” signal.

Related, not a wash

• Codex thread/resume fails with list_turns is not supported yet when continuing a desktop thread on Android #12462 — Codex thread/resume / list_turns is not supported yet on Android. Resume failure, not Start UX. See also fix(server): fall back to fresh Codex thread when resume hits unsupported list_turns #12468.
• [Bug]: Continue threads after restarts does not preserve Codex reasoning effort #10928 — restart continuation drops Codex reasoning effort. Same internal path, different bug.
• Discussion Recurring autonomous runs in one T3 Code thread #11654 — recurring scheduled runs. Different feature.
• feat(chat): continue interrupted turns with one tap #11716 — composer “Continue generation” on web/mobile, but it injects a synthetic "Continue" user message and only for interrupted turns. That is the workaround this issue wants to avoid, not the fix.
• feat(updates): continue active threads across server restarts #9167 — shipped promptless restart continuation. Internal only.

No open/merged PR implements Start/Resume without a synthetic continue.

Next step

Keep this open. The work is:

1. A client-reachable promptless turn-start (new command, or thread.turn.start without a user message) that calls sendTurn({ continuation: true }) only when the adapter supports it.
2. Composer Start/Resume on web and mobile for a non-running, resumable Codex thread (and any future promptless-capable provider), including remote/mobile session state and Stop after start.
3. Surface a Codex “needs input” failure instead of fabricating prompt text.
4. Optionally advertise promptlessTurnContinuation (and/or resumable session) so the button is not hardcoded.

#11716 can stay as a separate UX experiment; it should not close this issue.