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:

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.
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.
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.

Resume a long paginated thread whose history projection is wedged with expected ordinal N, got N-1.
Start a main-agent turn so the agent is actively working/pursuing its goal.
Submit /btw <unrelated side question> while the main agent is working.
Observe thread/fork failed ... expected ordinal 192591, got 192590 (code -32603).
Observe that <unrelated side question> is nevertheless injected into the existing main thread/turn and changes what the main agent is doing.
Submit /feedback <description of the failure> while the turn is active.
Observe that the literal /feedback ... text is injected as a Steer input into that same main turn.
Submit bare /feedback, select Bug, add the optional description, include diagnostics, and submit.
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: Failed to use /btw #38317, Resume opens a long thread at its first turn: 0.146.1 desynced thread_history projection cursors, and later versions never repair them #38792, Failed to fork current session through the app server #40537, and codex.exe exits with code 0 mid-session; thread-store then fails "expected ordinal N, got N-1" #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.

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

Failed to fork current session through the app server #40537

Powered by Codex Action

Exact screenshots from the original report. These are byte-for-byte copies of the supplied PNGs; SHA-256 was verified both before upload and after downloading the raw GitHub-hosted files.

1. `/btw` fork failure and fallback into the main conversation

sha256: 77457d0f22a099ab640ca71aeb0e31235ac6dbe6ca5dcc7e9fa212e05aabcd34

2. Inline `/feedback` delivered to the active main agent as a regular message

sha256: 1c27c40951907dd2d94b16d1f6412077501487c1ff5cb525851fc1f5dc79e0d4

3. Bare `/feedback` workflow ends with `feedback/upload failed in TUI`

sha256: 065c9f90557002cf6f8b7d7221dbae39f141e71c6efd7fc298891eb46ef9a43b

Raw files are hosted in this unlisted gist: https://gist.github.com/dllu/052dcc0ba99ac539e598ca65c6cbbd21

I reproduced the same feedback-upload 413 independently in Codex Desktop for macOS, without involving /btw or the TUI.

Environment

Codex Desktop 26.825.51511, build 7377
Bundled Codex CLI 0.151.0-alpha.7.2
macOS 26.5.2, arm64

Desktop reproduction

Open the feedback dialog from a long-running desktop task.
Leave Include current ChatGPT session logs enabled, which is the dialog default.
Enter feedback and submit.
The dialog reports only that it could not submit.

The matching local codex_feedback metadata shows:

classification="other"
include_logs=true
attachment_count=10
payload_bytes=570001124
status=413

The request failed after about 25.8 seconds with 413 Request Entity Too Large. The selected task transcript was over 565 MB. The local retry queue was empty, so this was a freshly assembled oversized payload rather than a stale queued upload.

I also audited all retained desktop logs from August 17 through August 31. They contain 11 failed manual feedback attempts across 8 tasks: 7 explicit 413 responses and 4 timeouts. A submission through the same feedback/upload method succeeds when session/browser diagnostics and extra files are disabled.

This suggests the unbounded-diagnostics failure is shared by the desktop and TUI surfaces. The client should preflight per-attachment and total sizes, omit or summarize oversized diagnostics, preserve the typed report, and offer a retry without diagnostics while showing the actual 413 cause. Defaulting diagnostics off would also prevent the failure.

No task IDs, report text, transcripts, app logs, browser data, screenshots, local paths, or extra files are included in this comment.

Update after comparing the affected installed binary with current main: PR #41569, Harden diagnostic report uploads, appears to implement the containment requested here and was merged on August 29.

The merged code:

sends the core feedback event before reading or uploading diagnostics;
sends attachments as separate gzip-compressed envelopes linked to the accepted event;
caps each decoded attachment envelope at 200 MiB and the compressed body at 40,000,000 bytes;
truncates oversized JSONL attachments on complete-record boundaries; and
preserves the accepted report even when a diagnostic attachment later fails.

The affected Codex Desktop build 26.825.51511 / bundled CLI 0.151.0-alpha.7.2 still contains the old uploading feedback to Sentry / payload_bytes single-envelope implementation and does not contain the new feedback event uploaded to Sentry or per-attachment failure paths. It produced the 570,001,124-byte envelope and HTTP 413 on August 31, about 48 hours after #41569 merged.

Could a maintainer confirm the first Codex Desktop build expected to contain #41569 and add the Desktop label to this issue? Keeping the issue open until the fix ships and is verified on Desktop would make the status much clearer to affected users.

Additional Desktop findings about where the diagnostics come from:

In build 26.825.51511, Help → Send Feedback sends a generic feedback command to the currently focused Codex window. Static inspection found no path that enumerates all pinned or open tasks.
The dialog nevertheless looks application-wide, defaults Include current ChatGPT session logs on, and does not name the selected task, state that no task is selected, or show the diagnostic size.

A dynamic correlation of all 22 retained manual uploads compared each feedback/upload task ID with the same primary renderer's latest ownerRoutePath when the request began:

21 of 22 matched.
One successful upload did not match. The primary window switched from one task route to another, and 596 ms later the feedback request began while still carrying the previous task ID. The new route remained active through completion. This proves that the feedback dialog can retain hidden stale task context after navigation; it is not merely a visual ambiguity.
In a separate 413 case, the request began with the matching task, but took 47.7 seconds to fail. The user navigated through other tasks while it was uploading, so the error appeared while a different task was visible. The error gave no indication which earlier task had supplied the oversized diagnostics.

For the 570,001,124-byte reproduction above, the task carried by feedback/upload matched the route when the request began, and its rollout accounted for approximately 558 MB. That specific attempt was not a global-cache attachment.

I also matched the prior “new task” report to a newly created fork. At its first failure, only 101 seconds after creation, its copied rollout already contained 829,661,473 bytes (791.2 MiB), 100,070 records versus 831,318,777 bytes, 100,175 records in the parent—99.8% of the parent's byte size. That storage-amplification issue is tracked in #35647.

So there are two interacting defects: newly created forks can already be enormous, and the feedback UI can retain an undisclosed previous task after navigation. A truly independent blank route has not been captured at the start of a retained upload, so I am not claiming that pinned tasks are globally scanned.

Alongside shipping #41569, please bind or clear the task at submit time, show the exact diagnostic source task (or “no task history”), and preflight its size.

No private task IDs, report text, transcripts, logs, browser data, screenshots, local paths, or extra files are included here.

Navigation Menu

Repository navigation

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

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

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

Codex doctor report

What issue are you seeing?

Exact `/btw` error

Evidence that the `/btw` payload went to the main thread

Evidence that inline `/feedback` went to the main thread

Root cause of the bare `/feedback` upload failure

What steps can reproduce the bug?

What is the expected behavior?

Additional information

1. `/btw` fork failure and fallback into the main conversation

2. Inline `/feedback` delivered to the active main agent as a regular message

3. Bare `/feedback` workflow ends with `feedback/upload failed in TUI`

Environment

Desktop reproduction

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

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

Codex doctor report

What issue are you seeing?

Exact /btw error

Evidence that the /btw payload went to the main thread

Evidence that inline /feedback went to the main thread

Root cause of the bare /feedback upload failure

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Aug 26, 2026

dllu commented on Aug 26, 2026

1. /btw fork failure and fallback into the main conversation

2. Inline /feedback delivered to the active main agent as a regular message

3. Bare /feedback workflow ends with feedback/upload failed in TUI

EthanSK commented on Aug 31, 2026

Environment

Desktop reproduction

EthanSK commented on Aug 31, 2026

EthanSK commented on Aug 31, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Exact `/btw` error

Evidence that the `/btw` payload went to the main thread

Evidence that inline `/feedback` went to the main thread

Root cause of the bare `/feedback` upload failure

1. `/btw` fork failure and fallback into the main conversation

2. Inline `/feedback` delivered to the active main agent as a regular message

3. Bare `/feedback` workflow ends with `feedback/upload failed in TUI`