Describe the bug
CloudCLI omits real user prompts when it restores Codex transcripts written by recent Codex CLI releases. Assistant messages, reasoning, and tool calls/results still render, but the user bubbles are absent after a page refresh or after leaving and reopening the session.
The prompt records are still present in the Codex JSONL. This is a history-rehydration compatibility issue, not transcript data loss.
Runtime reproduction:
- CloudCLI:
1.37.1
- Codex CLI:
0.149.0
- Platform: Linux x64
- Browser: Chrome
Static verification also shows that server/modules/providers/list/codex/codex-sessions.provider.ts has the same Git blob (9811e6daca3226fa036db42f344825949f830596) in CloudCLI v1.37.1, v1.37.2, and current main, so upgrading to 1.37.2 does not address this parser gap.
To Reproduce
- With Codex CLI
0.149.0, create an ordinary interactive Codex session and send one or more prompts.
- Let CloudCLI discover the session and open it in Chat.
- Refresh the page, or leave the session and reopen it.
- Observe that assistant/tool history is present but the user's prompts are absent.
- Inspect the rollout JSONL structurally (without changing it): the real prompts are stored as
response_item entries whose payload is type=message, role=user; there are no corresponding event_msg entries whose payload is type=user_message.
A representative 0.149.0 transcript had this shape:
event_msg / user_message: 0
response_item / message / role=user: 8
response_item / message / role=assistant: 25
The same boundary was observed across ordinary local CLI transcripts:
0.146.x: visible event_msg/user_message records were present.
0.147.0, 0.148.0, and 0.149.0: the sampled ordinary CLI transcripts had user prompts only in response_item/message/role=user.
- A transcript spanning both formats still shows only the legacy subset of user prompts in CloudCLI.
No prompt text, session identifier, path, credential, or private transcript has been included in this report.
Expected behavior
CloudCLI should restore real user prompts from both the legacy and current Codex rollout formats after refresh/reopen, while continuing to hide injected AGENTS, environment, system, developer, and permission scaffolding. Hybrid transcripts must not show duplicate user bubbles.
Root cause
The current history reader only creates user messages from:
entry.type === 'event_msg' && isVisibleCodexUserMessage(entry.payload)
It handles response_item/message only for role=assistant. See:
https://github.com/siteboon/claudecodeui/blob/v1.37.2/server/modules/providers/list/codex/codex-sessions.provider.ts#L295-L319
This behavior came from #488, which correctly stopped rendering every response_item role=user because some of those records contain expanded internal context such as AGENTS instructions and environment scaffolding:
#488
That safety requirement remains valid. Simply accepting every response_item role=user would regress the internal-context leak fixed by #488. However, relying exclusively on event_msg/user_message now drops all real user turns from recent ordinary Codex transcripts.
Possible direction
A compatibility path could:
- Continue preferring canonical visible
event_msg/user_message records when present.
- For newer turns without such an event, identify the actual turn input from
response_item/message/role=user using the persisted turn boundary/ordering rather than a broad string filter.
- Exclude the pre-turn bootstrap/internal-context user-role record.
- Deduplicate legacy/current records in hybrid transcripts.
- Preserve user images and file attachments.
- Add fixtures for legacy, current, hybrid, internal-context-negative, attachment, pagination, refresh, and reopen behavior.
Screenshots
Not included because the deterministic JSONL shape and reader branch identify the failure without exposing conversation content.
Error message
None. The history request succeeds; it silently returns no normalized user messages for the current format.
Additional context
- CloudCLI
1.37.2 release notes mention bounded/coordinated chat-history refreshes, but the Codex history reader itself is unchanged.
- The raw transcripts were not edited, truncated, moved, or rewritten during diagnosis.
Describe the bug
CloudCLI omits real user prompts when it restores Codex transcripts written by recent Codex CLI releases. Assistant messages, reasoning, and tool calls/results still render, but the user bubbles are absent after a page refresh or after leaving and reopening the session.
The prompt records are still present in the Codex JSONL. This is a history-rehydration compatibility issue, not transcript data loss.
Runtime reproduction:
1.37.10.149.0Static verification also shows that
server/modules/providers/list/codex/codex-sessions.provider.tshas the same Git blob (9811e6daca3226fa036db42f344825949f830596) in CloudCLIv1.37.1,v1.37.2, and currentmain, so upgrading to1.37.2does not address this parser gap.To Reproduce
0.149.0, create an ordinary interactive Codex session and send one or more prompts.response_itementries whose payload istype=message, role=user; there are no correspondingevent_msgentries whose payload istype=user_message.A representative
0.149.0transcript had this shape:The same boundary was observed across ordinary local CLI transcripts:
0.146.x: visibleevent_msg/user_messagerecords were present.0.147.0,0.148.0, and0.149.0: the sampled ordinary CLI transcripts had user prompts only inresponse_item/message/role=user.No prompt text, session identifier, path, credential, or private transcript has been included in this report.
Expected behavior
CloudCLI should restore real user prompts from both the legacy and current Codex rollout formats after refresh/reopen, while continuing to hide injected AGENTS, environment, system, developer, and permission scaffolding. Hybrid transcripts must not show duplicate user bubbles.
Root cause
The current history reader only creates user messages from:
It handles
response_item/messageonly forrole=assistant. See:https://github.com/siteboon/claudecodeui/blob/v1.37.2/server/modules/providers/list/codex/codex-sessions.provider.ts#L295-L319
This behavior came from #488, which correctly stopped rendering every
response_item role=userbecause some of those records contain expanded internal context such as AGENTS instructions and environment scaffolding:#488
That safety requirement remains valid. Simply accepting every
response_item role=userwould regress the internal-context leak fixed by #488. However, relying exclusively onevent_msg/user_messagenow drops all real user turns from recent ordinary Codex transcripts.Possible direction
A compatibility path could:
event_msg/user_messagerecords when present.response_item/message/role=userusing the persisted turn boundary/ordering rather than a broad string filter.Screenshots
Not included because the deterministic JSONL shape and reader branch identify the failure without exposing conversation content.
Error message
None. The history request succeeds; it silently returns no normalized user messages for the current format.
Additional context
1.37.2release notes mention bounded/coordinated chat-history refreshes, but the Codex history reader itself is unchanged.