Codex VS Code extension 0.145.x webview crash-loop causes perpetual loading spinner on Linux; 0.144.6 works

Start by comparing the 0.144.6 and 0.145.0-alpha.18 behavior around extension webview IPC and remote-control status handling. Reproduce on Linux and inspect exthost/openai.chatgpt/Codex.log alongside ~/.codex/logs_2.sqlite, focusing on the repeated client-status-changed and initialize cycle. Done means the sidebar initializes once and renders the chat interface without restarting.

What version of the IDE extension are you using?

26.715.31925 (stable), which bundles codex-cli 0.145.0-alpha.18 I also reproduced the same issue with pre-release version 26.5715.31925. The last version that works for me is 26.623.61825, which bundles codex-cli 0.144.6.

What subscription do you have?

ChatGPT Plus

Which IDE are you using?

Visual Studio Code 1.129.1

What platform is your computer?

Linux 6.12.95+deb13-amd64 x86_64, kernel 6.12, Node.js 22

What issue are you seeing?

After updating the Codex VS Code extension from version 26.623.61825 to a 0.145.x-based build, the Codex sidebar no longer loads.

The Codex icon appears, but the sidebar displays a perpetual loading spinner. The chat interface and prompt box never render.

The backend/app-server appears healthy:

Authentication succeeds.
GET https://chatgpt.com/backend-api/codex/models returns HTTP 200.
Plugins synchronize successfully.
Telemetry exports successfully.

However, the extension/webview repeatedly reconnects and initializes approximately every three seconds.

The app-server log repeats this sequence indefinitely on the same extension connection, ConnectionId(0):

app-server request: initialize request_id="1"
app-server event: remoteControl/status/changed targeted_connections=1
app-server request: config/read request_id="ExtensionFetchHandler:1"
app-server request: thread/list request_id="codex.chatSessionProvider:0"
... then it returns to initialize ...

The extension log at .../exthost/openai.chatgpt/Codex.log repeats:

[IpcRouter] I am the router
[CodexMcpConnection] Initialize received id=1
[IpcClient] Received broadcast but no handler is configured method=client-status-changed

There is no visible error message in the Codex UI because the UI never finishes loading.

The logs suggest that the app-server broadcasts client-status-changed, but no handler is registered for that event. The webview then appears to restart or reinitialize instead of transitioning from loading to ready.

This occurs with:

Stable extension: 26.715.31925
Pre-release extension: 26.5715.31925
Bundled codex-cli: 0.145.0-alpha.18

Downgrading to the following version restores normal operation:

Extension: 26.623.61825
Bundled codex-cli: 0.144.6

What steps can reproduce the bug?

1 Use Visual Studio Code 1.129.1 on Debian 13 Linux x64.
2 Install or update the OpenAI Codex extension to version 26.715.31925.
3 Open the Codex sidebar.
4 Observe that the sidebar remains on a perpetual loading spinner.
5 Observe that the chat UI and prompt box never render.
6 Inspect the extension log at:
.../exthost/openai.chatgpt/Codex.log
7 Observe the following message repeating:
[IpcClient] Received broadcast but no handler is configured method=client-status-changed
8 Inspect the app-server logs in the logs table of:
~/.codex/logs_2.sqlite
9 Observe the following request cycle repeating approximately every three seconds:
initialize
remoteControl/status/changed
config/read
thread/list
initialize
10 Close VS Code and move the existing local Codex state database out of the way:
mv ~/.codex/state_5.sqlite ~/.codex/state_5.sqlite.backup
11 Restart VS Code and reopen the Codex sidebar.
12 Observe that the issue still occurs with a newly created state_5.sqlite.
13 Downgrade the extension to version 26.623.61825.
14 Reopen the Codex sidebar.
15 Observe that the Codex chat interface loads normally.

The same failure also occurs with pre-release version 26.5715.31925.

What is the expected behavior?

Opening the Codex sidebar should initialize the extension once and then render the Codex chat interface, including the conversation area and prompt box.

The client-status-changed or corresponding remoteControl/status/changed event should be handled by the extension/webview without causing the webview to restart or repeatedly initialize.

The extension should behave as it did in version 26.623.61825, where the Codex panel loads and becomes usable.

Additional information

I bisected the issue between the following versions:

Last known working:
Extension 26.623.61825
codex-cli 0.144.6

Affected:
Extension 26.715.31925
codex-cli 0.145.0-alpha.18

Also affected:
Pre-release extension 26.5715.31925

Version 26.623.61825 works after removing a separately corrupted ~/.codex/state_5.sqlite.

Every tested 0.145.x-based build continues to crash-loop even when started with a fresh ~/.codex/state_5.sqlite. Resetting local state does not fix the regression.

The database remains named state_5.sqlite, so there does not appear to be a new state-schema migration involved.

The likely regression area is the extension webview IPC or remote-control status handling introduced between codex-cli 0.144.6 and 0.145.0-alpha.18.

In particular, this repeating log line may be relevant:

[IpcClient] Received broadcast but no handler is configured method=client-status-changed

This suggests the client-status-changed broadcast handler may not be registered before the status event is received, or may no longer be wired into the webview lifecycle.