openai / openai/codex

[Windows][26.908.40834] Second prompt remains in composer after first turn completes; no second turn or queue entry

Open
#45,404 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app app-server bug windows-os
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

Summary

Pressing Send on the second prompt in a Codex conversation in the Windows ChatGPT app hangs before Thinking starts. The text remains visible in the composer. The first task completed successfully, and the app can display and reopen the conversation.

Affected thread: 01a09f3b-68a4-72d3-b16b-1782ed2fbc07.

The unsent text is exactly:

In institutions images catalogue (browsing API) changing category causes to reset cells position. It should simply reuse cells positions with new images.

The user reports that prompts work through the Codex IDE extension. The general symptom is intermittent; this concrete case is a failed second message. The user now reports that updating works, so update/startup issues are outside this report.

Environment

  • Desktop internal version: 26.908.40834.
  • Store package: OpenAI.Codex 26.908.4834.0, Windows x64.
  • Windows 10 Home 22H2, build 19045.7725.
  • Desktop and IDE backend executables both report codex-cli 0.154.0-alpha.6.2.
  • IDE extension: openai.chatgpt-26.908.40401-win32-x64, VS Code Insiders.
  • Model: gpt-6-astra, reasoning max, default OpenAI provider.
  • Time zone: Europe/Warsaw, UTC+02:00.

Observed workflow

  1. Start a local task in the Windows app. The first prompt runs successfully.
  2. Enter the second prompt quoted above and press Send.
  3. Submission hangs, Thinking does not start, and the prompt stays in the composer.
  4. The conversation remains readable. Inspection after the first turn completed and after a later app session reopened the thread still finds only the first turn.

Expected: the second message should start or queue a turn, or show a recoverable error while preserving the draft.

The exact time of the failed click was not captured. The first turn's completion and the continued absence of a second accepted message are verified below.

Evidence for this exact thread

Snapshot taken September 14, 2026 at approximately 10:22:34 UTC / 12:22:34 local.

Evidence Result
First task started 09:24:27.547Z / 11:24:27 local
First task completed 09:54:05.480Z / 11:54:05 local
Stored turns Exactly one, status completed, error_json=null
Persisted user-message items Exactly one, the original prompt
Second prompt in target history/rollout Absent
Backend queue entries for this thread Zero
Local draft Exact 153-character second prompt is preserved
History projection Cursor is at EOF: 547 records, 47,139,082 bytes
Later thread resume 10:17:21.922Z, errorCode=null
Later app ownership/state assignedStreamRole=owner, latestTurnStatus=completed, turnCount=1

The preserved draft was read from:
electron-persisted-atom-state.composer-prompt-drafts-v2["local:<thread-id>"].prompt
in .codex-global-state.json. It also matches the retained composer document.

Across the inspected September 14 desktop logs, the only logged turn/start response for this thread is the first turn at 09:24:27.233Z. No subsequent turn/start, turn/steer, or thread/queue/add entry is recorded for this thread. No thread-specific warning/error, writer-conflict rejection, or compaction-steering rejection was found.

These observations establish that the second prompt remains local and has not become another persisted or queued turn. They do not identify the exact renderer gate that prevented submission.

Configuration and known-issue lead

The current base configuration parses successfully:

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "auto_review"

[windows]
sandbox = "elevated"

[desktop]
followUpQueueMode = "steer"
composerEnterBehavior = "enter"

No alternate profile is selected. Successful config/read and permission-profile responses appear in both relevant app sessions. This does not establish that the separate renderer home/workspace queries completed.

openai/codex#45069 describes the same second-message symptom on internal version 26.908.40834, with unresolved codex-home queries leaving the composer at loading-local-config. Comments also describe this on package 26.908.4834.0.

The installed bundles match the filenames in that report:

  • webview/assets/app-primary-17b54400f32a.js
  • webview/assets/app-initial-d9bed9d614d8.js

Read-only source inspection confirms the same configuration-readiness gate and a codex-home-loading managed-worktree query that is disabled while home data is absent without an error. Both relevant local startups also log home-path requests near query-cache-invalidate broadcasts. That timing is a correlation, not proof of lost responses.

The live renderer QueryClient was not inspected. Therefore #45069 is a strong candidate duplicate, not a confirmed root cause on this machine.

Request

Please correlate this exact thread with #45069 and inspect composer readiness, outstanding codex-home bridge requests, and local workspace materialization. The composer should time out/recover from unresolved readiness and surface an actionable error instead of retaining an indefinite pending submission.

No prompt was resubmitted during the investigation. No settings, drafts, databases, caches, or application processes were changed. The later app restart/resume described above was observed in existing logs, not initiated by the investigator.

Supporting evidence is embedded below. It retains the user-provided thread ID and prompt for correlation, but omits account identifiers, credentials, private paths, unrelated prompts, and raw conversation history. No feedback upload ID has been generated.

Redacted log excerpts and persistence checks
Focused evidence for thread 01a09f3b-68a4-72d3-b16b-1782ed2fbc07.
Snapshot: 2026-09-14T10:22:34Z. Local time is UTC+02:00.
Extracted fields, not complete raw log lines. Account identifiers, private paths,
request IDs, and unrelated content are omitted.

1. First turn starts successfully
Source: 2026/09/14/codex-desktop-3f7641fe-5ef4-4654-a413-163d3fecbab6-31208-t0-i1-091638-0.log:561
2026-09-14T09:24:27.233Z info [AppServerConnection] response_routed conversationId=01a09f3b-68a4-72d3-b16b-1782ed2fbc07 durationMs=24 errorCode=null method=turn/start originWebcontentsId=1

2. First turn completes
Source: same file:787
2026-09-14T09:54:05.572Z info [electron-message-handler] [desktop-notifications] show turn-complete conversationId=01a09f3b-68a4-72d3-b16b-1782ed2fbc07 turnId=01a09f3b-6dca-7e01-94e3-a274144c81a0
The rollout's task_complete timestamp is 2026-09-14T09:54:05.480Z.
There is exactly one task_started and one task_complete event.

3. Later app session resumes the same thread
Source: 2026/09/14/codex-desktop-e76d6315-7b68-43c5-a849-a6b164056f5e-25208-t0-i1-101652-0.log:274
2026-09-14T10:17:21.922Z info [AppServerConnection] response_routed conversationId=01a09f3b-68a4-72d3-b16b-1782ed2fbc07 durationMs=1247 errorCode=null method=thread/resume originWebcontentsId=1
Source: same file:276
2026-09-14T10:17:22.003Z info [AppServerConnection] response_routed conversationId=01a09f3b-68a4-72d3-b16b-1782ed2fbc07 durationMs=28 errorCode=null method=thread/turns/list
Source: same file:280
2026-09-14T10:17:22.318Z info [electron-message-handler] maybe_resume_success assignedStreamRole=owner conversationId=01a09f3b-68a4-72d3-b16b-1782ed2fbc07 latestTurnStatus=completed turnCount=1

4. Backend configuration read succeeds
Source: same file:316
2026-09-14T10:18:56.327Z info [AppServerConnection] response_routed durationMs=134 errorCode=null method=config/read originWebcontentsId=1

5. Startup correlation with the existing public report; not proof of a stuck query
Source: same file:41
2026-09-14T10:16:58.231Z info [electron-fetch-handler] codex-home request hostId=local
Source: same file:42
2026-09-14T10:16:58.265Z warning [IpcClient] Received broadcast but no handler is configured method=query-cache-invalidate
Source: same file:44
2026-09-14T10:16:58.314Z info [electron-fetch-handler] codex-home request hostId=local

6. Read-only persistence checks
thread_history_1.sqlite, scoped to this thread:
  thread_turns count = 1
  status = completed
  error_json = null
  userMessage item count = 1
  exact second-prompt matches in item_json = 0
  next_rollout_ordinal = 547
  next_rollout_byte_offset = 47139082

Target rollout:
  record count = 547
  file bytes = 47139082
  exact second-prompt matches = 0

queue_1.sqlite:
  queued_items count for this thread = 0

.codex-global-state.json:
  composer-prompt-drafts-v2["local:<thread-id>"].prompt matches exactly.
  composer-retained-documents-v1["local:<thread-id>"].prompt matches exactly.
  second prompt length = 153 characters.
  second prompt SHA-256 = 56f27ca5801779ca86a21fe26cf78e584c6cd67308fb29c4afa1f514d0f64e21

The only logged turn/start for this thread is the first turn shown above.
No second turn/start, turn/steer, thread/queue/add, or thread-specific warning/error
was found in the inspected September 14 desktop logs through this snapshot.
Target thread snapshot (JSON)
{
  "snapshot_utc": "2026-09-14T10:22:34Z",
  "thread_id": "01a09f3b-68a4-72d3-b16b-1782ed2fbc07",
  "originator": "Codex Desktop",
  "app_version": "26.908.40834",
  "package_version": "26.908.4834.0",
  "backend_version": "0.154.0-alpha.6.2",
  "first_turn_id": "01a09f3b-6dca-7e01-94e3-a274144c81a0",
  "first_task_started_utc": "2026-09-14T09:24:27.547Z",
  "first_task_completed_utc": "2026-09-14T09:54:05.480Z",
  "turn_count": 1,
  "turn_status": "completed",
  "turn_error": null,
  "user_message_item_count": 1,
  "second_prompt": "In institutions images catalogue (browsing API) changing category causes to reset cells position. It should simply reuse cells positions with new images.",
  "second_prompt_chars": 153,
  "second_prompt_sha256": "56f27ca5801779ca86a21fe26cf78e584c6cd67308fb29c4afa1f514d0f64e21",
  "exact_prompt_in_thread_draft": true,
  "exact_prompt_in_retained_composer": true,
  "exact_prompt_matches_in_rollout": 0,
  "exact_prompt_matches_in_history_items": 0,
  "queued_items_for_thread": 0,
  "rollout_records": 547,
  "rollout_bytes": 47139082,
  "projection_next_ordinal": 547,
  "projection_next_byte_offset": 47139082,
  "projection_at_eof": true,
  "successful_resume_utc": "2026-09-14T10:17:21.922Z",
  "resumed_stream_role": "owner",
  "resumed_latest_turn_status": "completed",
  "thread_specific_logged_turn_start_count": 1,
  "thread_specific_logged_turn_steer_count": 0,
  "thread_specific_logged_queue_add_count": 0,
  "thread_specific_logged_warning_error_count": 0,
  "live_renderer_query_state_inspected": false,
  "failed_click_timestamp_known": false,
  "investigator_resent_prompt": false,
  "investigator_changed_settings_or_draft": false
}

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by comparing this report with #45069 and inspect the renderer bundles webview/assets/app-primary-17b54400f32a.js and webview/assets/app-initial-d9bed9d614d8.js. Trace composer readiness, outstanding codex-home bridge requests, and local workspace materialization, using the reported thread and logs for correlation. Done means a second prompt starts or queues reliably, and unresolved readiness produces a recoverable actionable error instead of an indefinite pending composer.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, rust
Domain
desktop, frontend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.