Files
codex/codex-rs/feedback
Brent Traut 1f17e7512f Fix MIME types for path-backed feedback attachments (#30796)
## Why

Path-backed feedback attachments were always labeled `text/plain`, even
when the attached file was a gzip archive. Sentry consumers could
therefore UTF-8-decode a valid Codex Desktop log bundle and corrupt the
transferred bytes before anyone inspected it. Desktop already creates a
valid archive and sends its path through `feedback/upload`; the bad
metadata was assigned later by app-server's feedback upload path.

Slack investigation:
https://openai.slack.com/archives/C09NZ54M4KY/p1782867266569699

## What changed

Path-backed feedback attachments now derive their MIME type from the
final uploaded filename. Gzip files use `application/gzip`, known text
formats remain text, and unrecognized files use the safe
`application/octet-stream` fallback. Attachment filenames and bytes are
unchanged.

## How it works

- **Classify at the upload boundary:** The feedback crate selects MIME
metadata after resolving the final filename, including filename
overrides.
- **Preserve text rollouts:** Codex `.jsonl` rollouts remain
`text/plain`, while other known formats use the repository's existing
`mime_guess` mapping.
- **Protect unknown binaries:** Unrecognized extensions fall back to
`application/octet-stream` instead of being treated as UTF-8 text.
- **Keep the wire stable:** `feedback/upload` still accepts the same
path list, so Desktop, generated protocol surfaces, and remote-host
minimums do not change.

## Verification

Added focused coverage for gzip MIME, unknown binary fallback, `.jsonl`
text handling, and exact filename/byte preservation. Ran the complete
`codex-feedback` test suite (9 tests), crate-scoped Clippy, Rust
formatting, Bazel lock refresh, and diff checks successfully.
2026-07-03 13:06:07 -07:00
..