codex exec resume should support promptless follow mode for active goals

Summary

When features.goals is enabled, codex exec resume <thread-id> still requires a prompt or stdin and immediately starts a user turn. For long-running active goals, this forces wrappers and users to inject a synthetic prompt such as continue just to resume the existing goal.

It would be useful for codex exec resume to expose a promptless/follow mode that only resumes the thread and lets the existing app-server goal continuation machinery continue the active goal if the thread is idle.

Current behavior

A command like this works because it supplies stdin as the next user prompt:

codex exec \
  --enable goals \
  --model openai/gpt-5.5 \
  --dangerously-bypass-approvals-and-sandbox \
  resume 019e45eb-cb03-7123-bb36-3efc21390f32 \
  - < /tmp/agent_resume_prompt.md

But removing - < /tmp/agent_resume_prompt.md is not supported. codex exec resume expects a prompt argument or non-empty stdin and exits before it can act as a pure resume/follow operation.

This means headless users cannot naturally resume an active goal without adding a fake user message like continue.

Why this feels like a CLI gap

The lower-level app-server resume path appears to already have the semantics needed for this:

• thread/resume reopens/subscribes to the thread.
• When features.goals is enabled, app-server resume emits the goal snapshot and calls the goal continuation path (continue_active_goal_if_idle).
• That lets an active goal continue without a synthetic user prompt when the resumed thread is idle.

However, the codex exec resume CLI layer always constructs an initial user turn after resume, so there is no way to access that promptless goal-continuation behavior from the standard headless CLI entry point.

Proposed API

Add one of these equivalent modes:

codex exec resume --follow <thread-id>
codex exec resume --resume-only <thread-id>
codex exec resume --continue-goal <thread-id>

Expected behavior:

1. Resolve the thread id using the existing resume resolution logic.
2. Call app-server thread/resume.
3. Stream notifications/events to stdout, matching codex exec --json behavior when requested.
4. If an active goal exists and the thread is idle, let the existing goal continuation machinery start the next turn.
5. Do not require a prompt argument or stdin.
6. Do not inject a synthetic continue user message into history.

Use case

This matters for automation around long-running /goal tasks. A supervisor process may need to restart or reattach to a goal thread after process exit, machine restart, limit reset, or another external interruption. Today the only CLI-friendly workaround is to send an artificial continuation prompt. That mutates the conversation with a message that does not represent a real user instruction and can subtly affect model behavior.

A promptless follow/resume mode would let external controllers treat active goals as durable work items while preserving cleaner thread history.

Related issues

These are adjacent but not the same request:

• #16042 discusses cases where compaction fails to auto-continue and the user must manually send Continue.
• #17568 proposes codex exec fork; its open questions mention whether promptless fork should be allowed.
• #19910 discusses active goal continuation context being lost after compaction.
• #20958 proposes broader long-run /goal harness semantics, including avoiding premature stops when a clear goal-covered next action exists.
• #22132 discusses goal resume after quota exhaustion leaving a resumed thread in a stale approval state.

This issue is specifically about exposing app-server's promptless thread/resume + active-goal continuation path through codex exec resume.