Persisted session titles can become multi-kilobyte prompt blobs

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

1. 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).
2. Let the server persist the updated session index.
3. 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

Related

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.