Failed /btw and inline /feedback are injected into active main turn; feedback upload hits 413

What version of Codex CLI is running?

codex-cli 0.149.1 (current/latest according to codex doctor). The affected paginated thread was originally created by 0.148.0 and resumed in a 0.149.1 TUI before this incident.

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.6-sol, reasoning effort max

What platform is your computer?

Linux 6.17.0-1029-nvidia aarch64 aarch64
Ubuntu 24.04.4 LTS

What terminal emulator and version are you using (if applicable)?

Alacritty 0.17.0, no multiplexer. TERM=xterm-256color, COLORTERM=truecolor. The affected TUI was launched as codex --yolo from /home/dllu/proj/kitti-odometry.

Codex doctor report

codex doctor --json completed successfully and reported overallStatus: "ok". Relevant fields from the full report:

{
  "schemaVersion": 1,
  "generatedAt": "1787727070s since unix epoch",
  "overallStatus": "ok",
  "codexVersion": "0.149.1",
  "config": {
    "cwd": "/home/dllu/proj/kitti-odometry",
    "model": "gpt-5.6-sol",
    "model provider": "openai",
    "feature flags enabled": "42"
  },
  "runtime": {
    "install method": "npm",
    "platform": "linux-aarch64",
    "version": "0.149.1"
  },
  "state": {
    "active rollout files": "116 files, 4147851550 total bytes",
    "log DB integrity": "ok",
    "state DB integrity": "ok",
    "thread history DB integrity": "ok",
    "rollout/state DB parity": "ok"
  },
  "terminal": "Alacritty",
  "updates": "current version is not older"
}

What issue are you seeing?

There are three connected failure-containment problems in the TUI:

1. A failed /btw fork delivered the intended side-chat prompt to the active main turn instead. The main agent was mid-turn and pursuing a long-running goal, so this interrupted its current experiment and caused it to start handling the unrelated side request.
2. I then entered /feedback it failed to create a btw and sent my btw message to the main agent instead, interrupting the current work. That command was also persisted and delivered to the active main agent as an ordinary steering message instead of opening feedback.
3. Retrying with bare /feedback, then selecting Bug, entering the optional message, including diagnostics, and submitting did open the feedback workflow, but it ended with Failed to upload feedback: feedback/upload failed in TUI. The local logs show that Codex built a 1,122,741,593-byte Sentry envelope with five attachments and received HTTP 413.

This makes the /btw failure disruptive and then makes it impossible to report that disruption through the intended in-product feedback path.

Exact /btw error

Failed to start side conversation: thread/fork failed during TUI bootstrap: thread/fork failed: failed to prepare paginated fork: thread-store internal error: thread history projection for 01a01bcc-9190-7103-b112-2b8dec0eb5cb expected ordinal 192591, got 192590 (code -32603)

The underlying projection mismatch appears to be the same storage defect already reported in #38317 and #38792. This issue is specifically about command routing/failure containment after that error, plus the feedback upload path on a very large thread.

Evidence that the /btw payload went to the main thread

The intended side-chat text was:

how is it going? any new results to add to error_progress_and_pareto.png yet? Let's update the plot (and the script to generate it) with both accepted and rejected full suite results since the last update

After thread/fork failed, the stripped text (without /btw) was persisted at 2026-08-26T06:40:06.300Z as a role: "user" message in the existing main thread and existing active turn:

thread_id: 01a01bcc-9190-7103-b112-2b8dec0eb5cb
turn_id:   01a03c8a-1a40-70f3-9270-9460b41689c4
message:   how is it going? any new results ...

The main agent immediately acknowledged and began acting on that plot request before I clarified that it was intended for a separate side chat.

Evidence that inline /feedback went to the main thread

At 2026-08-26T06:40:48.464608621Z, ~/.codex/logs_2.sqlite recorded the literal input as a normal TurnInput submission with:

text: "/feedback it failed to create a btw and sent my btw message to the main agent instead, interrupting the current work"
mode: Steer { expected_turn_id: "01a03c8a-1a40-70f3-9270-9460b41689c4" }
thread_id: 01a01bcc-9190-7103-b112-2b8dec0eb5cb

The same literal text was persisted in the rollout as a user message, and the main agent responded to it. If inline arguments are unsupported for /feedback, the TUI should reject them or open the feedback dialog; it should not silently send the control command and its content to the model.

Root cause of the bare /feedback upload failure

The TUI only displayed the generic error, but the logs contain the actionable cause:

2026-08-26T06:43:35.475114962Z INFO codex_feedback
uploading feedback to Sentry thread_id=01a01bcc-9190-7103-b112-2b8dec0eb5cb classification="bug" include_logs=true attachment_count=5 payload_bytes=1122741593

2026-08-26T06:43:36.101301420Z WARN codex_feedback
feedback upload failed thread_id=01a01bcc-9190-7103-b112-2b8dec0eb5cb classification="bug" include_logs=true status=413 elapsed_ms=1273 error=failed to upload feedback to Sentry: HTTP status client error (413 Request Entity Too Large) for url (https://o33249.ingest.us.sentry.io/api/4510195390611458/envelope/)

At the time of inspection the active rollout itself was about 1.11 GB. The feedback bundle appears to include effectively unbounded session diagnostics.

What steps can reproduce the bug?

The exact affected thread is 01a01bcc-9190-7103-b112-2b8dec0eb5cb (history_mode: "paginated"). It was a six-day, very large thread with an active persistent goal.

1. Resume a long paginated thread whose history projection is wedged with expected ordinal N, got N-1.
2. Start a main-agent turn so the agent is actively working/pursuing its goal.
3. Submit /btw <unrelated side question> while the main agent is working.
4. Observe thread/fork failed ... expected ordinal 192591, got 192590 (code -32603).
5. Observe that <unrelated side question> is nevertheless injected into the existing main thread/turn and changes what the main agent is doing.
6. Submit /feedback <description of the failure> while the turn is active.
7. Observe that the literal /feedback ... text is injected as a Steer input into that same main turn.
8. Submit bare /feedback, select Bug, add the optional description, include diagnostics, and submit.
9. Observe Failed to upload feedback: feedback/upload failed in TUI; inspect logs_2.sqlite and see a >1.1 GB payload followed by HTTP 413.

Additional local state at the time of failure:

thread_history_projection_state.next_rollout_byte_offset = 1100330606
thread_history_projection_state.next_rollout_ordinal     = 192591
max projected thread_items.rollout_ordinal               = 192588
live writer error                                        = expected 192591, got 192590

Hundreds of identical live-writer warnings were emitted while the TUI otherwise continued operating.

What is the expected behavior?

• /btw should be atomic with respect to the main conversation. If the fork cannot be created, its payload should remain in the composer or be recoverable for retry, and it must never be dispatched to the main thread. The active agent/goal should continue uninterrupted.
• Slash commands should never silently fall through as model input. /feedback <text> should either open/prefill the feedback flow or show a validation error.
• Feedback diagnostics should enforce per-attachment and total size caps, omit/summarize oversized rollouts/logs, and offer a retry without logs rather than constructing a >1 GB envelope.
• If upload still fails, the TUI should surface the HTTP status/root cause (here, 413 Request Entity Too Large) and preserve the typed report for retry.

Additional information

• Incident time: approximately 2026-08-25 23:40-23:43 PDT / 2026-08-26 06:40-06:43 UTC.
• The active TUI process was running CLI 0.149.1. The thread's original session_meta says CLI 0.148.0, so this also exercises resume/version transition behavior.
• The three screenshots captured the fork error, both messages appearing in the main transcript, and the generic feedback-upload error. All important visible text is transcribed above because gh issue create has no first-party local attachment support.
• Related underlying projection reports: #38317, #38792, #40537, and #40630.
• The documented behavior says /side//btw starts a temporary side chat without interrupting the main chat, and /feedback opens a feedback flow that can include diagnostics.

Start at the TUI handlers for /btw and /feedback, then trace the thread/fork and feedback upload paths described in the report. Reproduce the paginated-thread failure and inspect the recorded logs_2.sqlite evidence. Done means failed forks never dispatch their payload to the main turn, inline slash commands are validated or opened as workflows, and oversized diagnostic uploads fail safely with a retryable report.