Persisted session titles can become multi-kilobyte prompt blobs

Resolved 💬 3 comments Opened Mar 23, 2026 by shanelindsay Closed Mar 23, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Persisted Codex session titles can become extremely long when a client sends a raw prompt/body as the thread name. The server currently appears to accept almost any non-empty thread_name and writes it straight into session_index.jsonl.

This causes broken session list UX and can leak large prompt blobs into persisted session metadata.

Repro

Send or trigger a thread/name/set path with a very long multi-line string (for example, a full prompt body or issue template text).
Let the server persist the updated session index.
Inspect ~/.codex/session_index.jsonl.

Actual

The raw multi-line / multi-kilobyte text is persisted as thread_name.

In my local index I found titles many kilobytes long, including one around 8.7k characters and others over 1k characters.

Expected

Persisted session titles should be normalised defensively on the server side:

trimmed
single-line (collapse newlines / repeated whitespace)
bounded to a sane maximum length

Why this seems server-side

I traced this locally and found that the persistence path appears to trust the provided thread name after only minimal normalisation. Meanwhile, some client-side title generators already produce short names, so a single bad client or rename path can still poison the authoritative session index.

Suggested fix

Harden the shared thread-name normaliser so persisted names are always safe even if a client misbehaves.

Something along these lines:

trim
collapse all whitespace/newlines to single spaces
drop empty results
cap length to a fixed maximum before persisting

This seems adjacent to session naming / rename UX issues such as #4163, but it looks like a distinct bug rather than a feature request because malformed titles are already being persisted.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 5 months ago

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

#13855
#14291

Powered by Codex Action

s1korrrr · 5 months ago

I reproduced this locally and prepared a tested fix on a public branch.

Root cause: thread name normalization currently only trims leading/trailing whitespace, so pasted multi-line or very large values can be persisted into session_index.jsonl and later render as giant blobs in the thread list.

Fix on branch: feat/thread-name-normalization
Compare: https://github.com/openai/codex/compare/main...s1korrrr:codex:feat/thread-name-normalization
Commit: eebb23df2

What changed:

normalize thread names by collapsing internal whitespace/newlines to single spaces
reject names that normalize to empty
bound persisted names to 120 chars
normalize existing session-index reads too, so previously polluted entries stop rendering as blobs

Validation:

cargo test -p codex-core normalize_thread_name_collapses_whitespace_caps_length_and_rejects_empty
cargo test -p codex-core scan_index_
cargo test -p codex-core find_thread_
just fix -p codex-core
./tools/argument-comment-lint/run.sh

I still can’t open an upstream PR directly because the repo is currently collaborators_only, but if this approach aligns with the intended fix, I’d be happy to open an invited PR from that branch.

etraut-openai contributor · 5 months ago

I don't think this is a bug. It is not the app server's job to trim or truncate text sent to the thread/name/set API. The client should avoid sending really long text here. If a client is specifying titles that are many K in size, I'd consider that a client bug.