[Bug][macOS 26.602][Mac Codex App] Composer controls and config-backed settings receive clicks but silently do nothing

What version of the Codex App are you using (From "About Codex" dialog)?

26.602.40724

Bundle version: 3593

What subscription do you have?

Codex Enterprise Seat

What platform is your computer?

macOS 26.5 (25F71), arm64

Runtime shown in local Sentry context:

• Electron/Chrome 149.0.7827.54
• Node 24.14.0

What issue are you seeing?

After updating to Codex Desktop 26.602.40724, most controls in the main composer are visible and receive clicks, but do not do anything. There is no error message or disabled-state explanation.

Controls that are inert:

• Project selector, e.g. universe
• Work mode selector, e.g. Work locally
• Branch selector, e.g. master
• Model selector, e.g. 5.5 Extra High
• Add file / plus button
• Approval mode dropdown, e.g. Approve for me

Controls that still work:

• Send
• Dictate / microphone
• Text input

This is not limited to the composer:

• Settings controls whose values appear to be backed by config.toml also appear frozen or do not reflect changes reliably.
• I could not switch between settings for different projects.
• Settings navigation itself is clickable, and text fields still accept focus/input, so the issue appears to affect specific control actions/state updates rather than all UI input.

This does not look like macOS/Electron losing mouse events. Local Sentry breadcrumbs show ui.click events reaching the renderer for affected controls. Examples around the repro window:

2026-06-07T06:06:38Z ui.click button[aria-label="Start new chat in universe"][type="button"]
2026-06-07T06:07:35Z ui.click span.min-w-0.flex-1.truncate.select-none
2026-06-07T06:08:01Z ui.click span._labelXs_...text-token-text-link-foreground
2026-06-07T06:12:14Z ui.click button[aria-label="Add files and more"][type="button"]

After restarting with Browser Use and Computer Use disabled, the same pattern persisted. Sentry breadcrumbs showed clicks reaching Settings controls and project/settings-related controls:

2026-06-07T06:39:20Z ui.click button[aria-label="Keyboard shortcuts"][type="button"]
2026-06-07T06:39:22Z ui.click button[aria-label="General"][type="button"]
2026-06-07T06:39:27Z ui.click button[aria-label="Detached"][type="button"]
2026-06-07T06:39:28Z ui.click button[aria-label="Inline"][type="button"]
2026-06-07T06:39:44Z ui.click button#radix-...w-[240px]...[type="button"]
2026-06-07T06:40:16Z ui.click button[aria-label="Computer use"][type="button"]
2026-06-07T06:40:45Z ui.click div[aria-label="arca.codex"] > div...
2026-06-07T06:40:56Z ui.click button[aria-label="Environments"][type="button"]
2026-06-07T06:40:57Z ui.click button[aria-label="Worktrees"][type="button"]

The app did not appear to crash:

Sentry session status: ok
Sentry session errors: 0
Sentry queue: []

Normal app RPCs continued to return, including model/list, config/read, thread/list, and turn/start, which matches the symptom that composer text input and Send still work.

Post-restart logs show config/read returning successfully and some config/batchWrite requests also returning successfully, but UI state/context still appeared stuck:

2026-06-07T06:38:36Z method=config/read errorCode=null
2026-06-07T06:40:30Z method=config/batchWrite errorCode=null
2026-06-07T06:40:32Z method=config/batchWrite errorCode=null
2026-06-07T06:40:36Z method=config/batchWrite errorCode=null
2026-06-07T06:40:41Z method=config/batchWrite errorCode=null
2026-06-07T06:40:51Z method=config/batchWrite errorCode=null
2026-06-07T06:40:52Z method=config/batchWrite errorCode=null

That makes this look less like a backend/config read failure and more like the UI not opening/selecting/refocusing/re-rendering correctly after click actions, especially around project-scoped settings and shared composer dropdown controls.

What steps can reproduce the bug?

1. Open Codex Desktop 26.602.40724.

• Feedback ID: 019ea0ad-da42-7433-82de-2bb56264015b

1. Go to the main composer.
2. Click the project selector, work mode selector, branch selector, model selector, approval dropdown, or add-file button.
3. Observe that the click appears to hit the UI, but no menu opens, no file picker opens, and no error is shown.
4. Confirm that Send, Dictate, and text input still work.
5. Disable Browser Use and Computer Use.
6. Restart Codex Desktop.
7. Re-test the same composer controls.
8. Open Settings and try changing config-backed controls or switching between settings for different projects.

Observed result:

• Composer controls remain frozen after restart.
• Settings/project-scoped controls also appear stuck or do not reflect changes reliably.
• Click events are recorded locally, but the expected menu/action/state change does not reliably happen.

What is the expected behavior?

Clicking visible controls should either:

• open the relevant selector/menu/file picker,
• apply the selected setting/project context, or
• show an explicit disabled-state reason or error.

The current silent no-op is difficult to diagnose because the UI looks enabled and records the click.

Additional information

This started after the recent update. It was working before the update.

Possibly related older report: https://github.com/openai/codex/issues/15346

Suspicious local log signal around the same time window:

2026-06-07T06:06:38Z IAB_LIFECYCLE received browser sidebar owner sync conversationId=new-conversation ownerRoutePath=/
2026-06-07T06:06:39Z IAB_LIFECYCLE captured session route conversationId=...
2026-06-07T06:06:40Z error Received turn/started for unknown conversation conversationId=...
2026-06-07T06:06:50Z error Received turn/completed for unknown conversation conversationId=...
2026-06-07T06:07:52Z error Received turn/completed for unknown conversation conversationId=...
2026-06-07T06:07:54Z error Received turn/started for unknown conversation conversationId=...

App state snapshots later in the session also showed unexpectedly high browser/session state:

browser_use_window_count=1
browser_use_conversation_count=21
browser_use_session_route_count=26
thread_count_streaming_owner=4
inflight_turn_count=2
renderer_process_working_set_kb≈1,000,000
host_descendant_process_count_total≈800

There were also slow-but-successful calls, e.g. thread/list around 6s and mcpServerStatus/list around 13s, but the most actionable part is that clicks are recorded and then silently fail to produce the expected menu/action.