Final response is incorrectly placed inside the Thinking/“Worked for” section, leaving no visible output #41948

Activity

1. lliooly

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Sep 1, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   on Sep 1, 2026
3. github-actions commented on Sep 1, 2026

   

   github-actionsBot

   on Sep 1, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Desktop messages remain invisible until restart while MCP approval dialogs still appear #41733

   Powered by Codex Action
4. lliooly commented on Sep 1, 2026

   

   lliooly

   on Sep 1, 2026

   Author

   More actions

   Thanks — I reviewed #41733. This appears to be a different issue.

   In #41733, assistant messages are missing from the timeline entirely and become visible again after restarting the app, in a Windows + MCP Elicitation scenario.

   In my case, the final assistant response appears to be incorrectly associated with or rendered inside the Thinking / “Worked for …” section, leaving the normal final response area empty. I’m seeing this on macOS, and it does not require MCP.

   So while both may belong to the same general family of Desktop rendering/state synchronization bugs, the observed failure mode is different.
5. vrudik commented on Sep 6, 2026

   

   vrudik

   on Sep 6, 2026 – with ChatGPT Codex Connector

   More actions

   Additional deterministic reproduction and candidate source-level fix for this symptom, observed on Codex desktop 26.901.6511.0, Windows x64, Microsoft Store build.

   What was isolated

   A non-empty completed final_answer is present in both persisted paginated history and the history API response. A late commandExecution completion is appended after that final answer, including after the turn-completed record. Reopening the task leaves the normal final-response area empty while keeping the answer inside the collapsed “Worked for…” activity group.

   This is not evidence that the answer text was deleted. The observed late command was a long-running diagnostic process. Its result arrived after the assistant's final answer.

   Minimal normalized renderer input

   const items = [
     {
       type: 'assistant-message',
       searchItemId: 'synthetic-final',
       content: 'Synthetic final answer',
       phase: 'final_answer',
       completed: true,
     },
     {
       type: 'exec',
       callId: 'synthetic-late-exec',
       commandExecutionItemId: 'synthetic-late-exec',
       executionStatus: 'failed',
       completed: true,
       output: { exitCode: 1 },
     },
   ];
   // Pass items to split-items-into-render-groups with status 'completed'.

   Expected: assistantItem is the synthetic final answer, and the command remains an activity item.

   Observed with the original installed splitter: assistantItem is null; both objects remain in agentItems. The text is preserved, but the final answer is collapsed with activity.

   Selection logic

   The affected installed module is split-items-into-render-groups-1d07f8e220e8.js. It selects the separate assistant response from the activity tail. Its backward fallback skips certain trailing reasoning/subagent/elicitation events, but does not skip a late exec result, so this case never reaches the explicit final answer.

   Candidate change: for a completed turn, prefer its latest eligible completed explicit final answer, then use the existing extraction logic. Keep the ordinary fallback for other cases. Eligibility must preserve the existing async-delivery and exclusion checks.

   Equivalent source-level proposal:

   if (turnStatus === 'completed') {
     const finalIndex = activityItems.findLastIndex(item =>
       item.type === 'assistant-message' &&
       item.phase === 'final_answer' &&
       item.completed === true &&
       item.delivery !== 'async' &&
       shouldExcludeAssistantMessage?.(item) !== true
     );
     if (finalIndex >= 0) assistantIndex = finalIndex;
   }
   // Existing extraction and deduplication logic remains unchanged.

   Do not reorder persisted history or discard late tool results to work around the rendering issue.

   Verification status

   The original module was checked byte-for-byte against the installed ASAR entry. The candidate changes only source-level answer selection, not fixture order or persisted history.

   • Original-module control: 5 passing, 7 failing behavioral tests. Failures cover late exec, MCP, patch and async-question tails, latest-final selection, completed-vs-unfinished-final selection, and combined preservation with a late command.
   • Patched-module run: 15 passing, 0 failing tests: the same 12 behaviors plus guards against missing/ambiguous source anchors and double application.
   • Existing behavior is checked for in-progress turns, legacy phase-less assistant tails, exclusion callbacks and commentary-only histories. Tests also assert that activity order, text, command data and pending input are preserved.

   The source-level candidate and its regression tests have passed independent review. This is not a packaged-client integration test.

   Deployment and privacy

   This is a source-level candidate, not an installed-client fix. The Store package remains unchanged; it requires a vendor-signed release. The test harness isolates the original splitter with bundler/dependency adapters, rather than testing the full desktop UI.

   No private conversation text, task/session identifiers, local usernames, personal paths, screenshots, credentials, or full logs are included here. The input above is synthetic. Separate archive/startup symptoms have not been attributed to this rendering defect.
6. lliooly

   closed this as completedon Sep 17, 2026