VS Code extension 26.5707.* opens blank webview on Linux; 26.5623 works but lacks 5.6-Sol

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

• #31149

Powered by Codex Action

Potential duplicates detected. Please review them and close your issue if it is a duplicate. * VS Code extension webview fails to mount, reports unknown openai-codex session, and floods IPC broadcasts on Windows #31149 _Powered by Codex Action_

I reviewed #31149. This may be related, but this report is not identical:

• Linux x64, not Windows
• reproducible across 26.5707.30751 / 26.5707.31123 / 26.5707.31428
• rollback to 26.5623.141536 restores the UI
• rollback blocks access to 5.6-Sol
• main observed symptom is webview never reaching [startup][renderer] app routes mounted

Happy to provide the relevant Codex.log snippets if useful.

I recomend not to roll back version and always use the latest version --- there is a certain update that filters which models you can view based on capacity ---

I promise you , you will not be disapointed with the smaller models , Tera and Luna ,,, because they are so much better than 5.5 and 5.4 (I will happliy use older models too btw)

as per 5.6 Tera and Luna , are actually very novel and cool, a great speed improvement with those models.... I assume 5.6 are trained for more use-cases -- so you should be much happier because more use-cases are not covered -- due to the massive amount of new users who joined with the 5.5 release

know that if SOL is missing I think its by design. maybe there is some issue with Chinese users who try to access it which has some regulatory burden, but despite that --- its a service issues, not a bug with the software are using please use the latest version of codex

but I understand how you may like older bersion of things, and how things can break once you update - but with codex things dont really break in terms of the codex too. Im not going to blame openai if there is very minor amount of outages, considering how many new users have joined, and how hard it is to host language models (its the same issue as delivering the internet in the 90s and a little bit harder because its a new issue, after things got refained and establised -- its a new century with the age of ai --- I also think its cool because the semiconductor indurstry also used ML even back in 2005 - for packaging - so you can see why the investment comes )

same problem

Same here. Latest vscode pre-release extension (26.5707.31428) + latest codex (0.144.1) = blank screen.

Sama issue here.
Hope they fix this as soon as possible

I am having this issue also

OS: Kubuntu 26.04, native Wayland
VS Code: 1.128.0
GPU: NVIDIA, driver 595.58.03

Extension activates and app-server initializes but the Codex webview remains blank or in perpetual loading of the OpenAI icon.

1:2026-07-10 09:46:27.893 [info] Activating Codex extension
2:2026-07-10 09:46:27.893 [info] [CodexMcpConnection] Spawning codex app-server
4:2026-07-10 09:46:27.893 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed
7:2026-07-10 09:46:27.923 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed
8:2026-07-10 09:46:28.017 [info] [CodexMcpConnection] Initialize received id=1

VS Code renderer sometimes terminates with SIGBUS, and Chromium reports TransferBuffer::Initialize and AllocateRingBuffer failures

Launching with --disable-gpu allows the extension to load instantly.

I'm having the same issue but rolling back to a previous version of the extension doesn't seem to help on my system

I am having this issue also OS: Kubuntu 26.04, native Wayland VS Code: 1.128.0 GPU: NVIDIA, driver 595.58.03 Extension activates and app-server initializes but the Codex webview remains blank or in perpetual loading of the OpenAI icon. 1:2026-07-10 09:46:27.893 [info] Activating Codex extension 2:2026-07-10 09:46:27.893 [info] [CodexMcpConnection] Spawning codex app-server 4:2026-07-10 09:46:27.893 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed 7:2026-07-10 09:46:27.923 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed 8:2026-07-10 09:46:28.017 [info] [CodexMcpConnection] Initialize received id=1 VS Code renderer sometimes terminates with SIGBUS, and Chromium reports TransferBuffer::Initialize and AllocateRingBuffer failures Launching with --disable-gpu allows the extension to load instantly.

This fixed it for me, thank you!

I can confirm a very similar regression in a Remote-SSH setup.

Environment:

• IDE: VS Code Desktop using Remote-SSH
• Remote host: Linux x86_64
• Extension: openai.chatgpt
• Failing version observed locally: 26.707.31428 (openai.chatgpt-26.707.31428-linux-x64)
• Working rollback: 26.623.70822
• Bundled CLI in both tested extension directories reported codex-cli 0.142.4

Symptoms:

• After the Marketplace update, the Codex sidebar opened but stayed stuck/loading.
• The extension installed successfully and activated.
• Codex.log showed that the bundled codex app-server was spawned and Initialize received id=1, so this was not a CLI path issue or app-server startup failure.
• Earlier sessions also showed fetch/model-refresh symptoms, but after proxy configuration was addressed, the remaining hard failure was still present.

Relevant logs:

[info] [CodexMcpConnection] Spawning codex app-server
[info] [CodexMcpConnection] Initialize received id=1
[error] PendingMigrationError: navigator is now a global in nodejs,
please see https://aka.ms/vscode-extensions/navigator for additional info

The stack pointed into the updated Codex extension bundle:

.../extensions/openai.chatgpt-26.707.31428-linux-x64/out/extension.js

Local comparison:

• The older working extension version guarded browser checks via typeof window / window.navigator.
• The failing newer version directly touched typeof navigator / navigator?.userAgent.
• In the Remote-SSH Node extension host, that direct navigator access triggers VS Code's migration guard and breaks the extension/webview path.

Workaround:

• Rolling the remote extension registration back to openai.chatgpt-26.623.70822-linux-x64 restored the sidebar.
• The incompatible 26.707.31428 directory was marked obsolete so VS Code would not keep loading it.

This looks consistent with a frontend / extension-host compatibility regression in the newer extension train, rather than a backend account issue or failure to spawn the bundled Codex CLI.

can you provide a screenshot of the blank webview?

try use with /feedback within the same chat session

There is no chat session since the webview cannot load.

<img width="642" height="1130" alt="Image" src="https://github.com/user-attachments/assets/72ad27ca-0120-41d1-aa7a-91e0b2254f3f" />

Seeing the same issue here. completely blocked from working :( codex forced me to update as older version was no longer supported, but clearly the new version doesn't work at all.

I recomend not to roll back version and always use the latest version --- there is a certain update that filters which models you can view based on capacity --- I promise you , you will not be disapointed with the smaller models , Tera and Luna ,,, because they are so much better than 5.5 and 5.4 (I will happliy use older models too btw) as per 5.6 Tera and Luna , are actually very novel and cool, a great speed improvement with those models.... I assume 5.6 are trained for more use-cases -- so you should be much happier because more use-cases are not covered -- due to the massive amount of new users who joined with the 5.5 release know that if SOL is missing I think its by design. maybe there is some issue with Chinese users who try to access it which has some regulatory burden, but despite that --- its a service issues, not a bug with the software are using please use the latest version of codex but I understand how you may like older bersion of things, and how things can break once you update - but with codex things dont really break in terms of the codex too. Im not going to blame openai if there is very minor amount of outages, considering how many new users have joined, and how hard it is to host language models (its the same issue as delivering the internet in the 90s and a little bit harder because its a new issue, after things got refained and establised -- its a new century with the age of ai --- I also think its cool because the semiconductor indurstry also used ML even back in 2005 - for packaging - so you can see why the investment comes )

You did no get it - the whole Codex window is blank, there is nothing in it at all.

It seems that this problem has been temporarily solved.

Environment

• Local client: macOS + VS Code
• Remote host: Linux x86_64 over Remote-SSH
• VS Code Server: 1.123.0
• Extension: openai.chatgpt / Codex, installed on the remote side
• Broken build observed: 26.5707.31428
• Workspace: remote Linux workspace

Original failure

After updating the remote Codex extension, the Codex sidebar/Webview became blank.

The remote extension-host log showed that Codex activation started and then failed with:

ExtensionService#_doActivateExtension openai.chatgpt,
  activationEvent: 'onView:chatgpt.sidebarSecondaryView'

PendingMigrationError: navigator is now a global in nodejs
The stack pointed directly into the remote Codex extension:
~/.vscode-server/extensions/openai.chatgpt-<version>-linux-x64/out/extension.js
I also tried another installed Codex build (26.707.31428), but it produced the same PendingMigrationError in my Remote-SSH extension host, so that was not a useful rollback for this environment.
Recovery attempt that currently works
I then ran:
Remote-SSH: Kill VS Code Server on Host
After that:
I reopened VS Code locally.
I reconnected to the same Remote-SSH host.
I opened Codex locally and installed/enabled the Codex extension on the remote side again.
The Codex UI rendered and became usable in the existing Remote-SSH workspace.
At the moment I have not disconnected/reconnected again, because I do not want to disturb the recovered session. Therefore, I cannot claim this is a reliable fix yet.

https://github.com/openai/codex/issues/32041#issuecomment-4933694048

This fixed it for me.
Thank you

I am having this issue also, I'm using remote-ssh. The local Codex plugin works fine, but the remote Codex freezes.

--disable-gpu doesn't do anything.

I am having this issue also, I'm using remote-ssh. The local Codex plugin works fine, but the remote Codex freezes. --disable-gpu doesn't do anything.

My problem is purely local

I encounter the same problem. Linux 5.15.185-tegra aarch64 aarch64（AGX orin）

--disable-gpu

This worked for me. Thanks!

I confirm that --disable-gpu works.

Additional testing on the originally reported machine (Linux x64, VS Code 1.128.0):

• Also reproduced on 26.5707.41301 (newer than the builds listed above) — same blank panel.
• File-descriptor limits are not the cause here: the running VS Code process already has NOFILE 1048576/1048576 (verified via prlimit), far above the 65536 suggested in the workaround and far above the number of files in VS Code workspace.
• Not the GPU path reported by @keanutoomer: our logs contain no SIGBUS / TransferBuffer / AllocateRingBuffer errors.
• Not the Remote-SSH navigator regression reported by @lcneyc: local session, no PendingMigrationError in exthost logs.

Log signature in failing 26.5707.* sessions: extension activates, app-server starts, Initialize received id=1 — but the webview never logs React root render requested. Meanwhile renderer.log repeatedly warns:

Attempted to report in-progress status for unknown chat session type 'openai-codex'

which matches the symptom described in #31149 — so that issue may not be Windows-specific. (Note: the warning occasionally appears in working sessions too; the hard discriminator is the missing React root render.)

Working rollback 26.623.141536 on the same machine logs React root render requested followed by [startup][renderer] app routes mounted after 4355ms.

@benjpau

as per @zhang-wenchao , how did you realize it ? thats a vague thing to figue

> --disable-gpu This worked for me. Thanks!

oh wow, maybe this can be traced to something with VS-code itself?
and perhaps add a new test scheme - (because codex-ide is so big and so widely used)

This is most likely caused by a combination of many factors. I’m currently using a very old version codex extension of remote-ssh without any issues.

26.513.21555

@benjpau as per @zhang-wenchao , how did you realize it ? thats a vague thing to figue > > --disable-gpu > > This worked for me. Thanks! oh wow, maybe this can be traced to something with VS-code itself? and perhaps add a new test scheme - (because codex-ide is so big and so widely used)

@Mahkhmood9 Something like this:
open -na "Visual Studio Code" --args --disable-gpu

I'm using macOS.

Confirmed on three Ubuntu 26.04 machines with Codex 26.5707.41301 and VS Code 1.128.0. Windows and macOS machines using the same account are unaffected. The bundled app-server starts successfully. Developer: Reload Webviews sometimes restores the panel, but the failure returns intermittently and has worsened across recent extension releases.

I confirm that --disable-gpu works.

Ubuntu 24.04
VS Code 1.128.0

I found a little workaround. I ran into this issue while using VS Code on a remote server. After updating the Codex CLI on the server to the latest version (v0.144.1), I connected to that remote server through the Codex app, and it worked.

Second that -- --disable-gpu worked for me (Ubuntu 22.04)

remote-ssh is still unavailable; hopefully, a solution can be found soon.

remote-ssh is still unavailable; hopefully, a solution can be found soon.

I assume you can just tell the agent
make me a SKILL about connecting to an ssh ,, the detailed are opc@localhost -i privatekey.pub , use this idea
can you show errors?

but i understand if you are not using english to talk to the llm, its not meant to be used with something that isnt Spanish Or English --- anything like Arabic or Russian Or Chinese will fail

I also thikn its a good metric for eval , like DeepSWE (qeustions in Madarin or Catonese or Taiwanese Hokkien[which is used very often and sometimes responds in Mandarin when the text was Taiwanese Hokkien, I know for a fact with 5.5 , dont know about 5.6 ] )

)))

For anyone use ubuntu vscode desktop version, add a desktop file to overwrite the global one:

[Desktop Entry]
Name=Visual Studio Code
Comment=Code Editing. Redefined.
GenericName=Text Editor
Exec=/usr/bin/code --disable-gpu %F
Icon=vscode
Type=Application
StartupNotify=false
StartupWMClass=Code
Categories=TextEditor;Development;IDE;
MimeType=application/x-code-workspace;
Actions=new-empty-window;
Keywords=vscode;

[Desktop Action new-empty-window]
Name=New Empty Window
Name[cs]=Nové prázdné okno
Name[de]=Neues leeres Fenster
Name[es]=Nueva ventana vacía
Name[fr]=Nouvelle fenêtre vide
Name[it]=Nuova finestra vuota
Name[ja]=新しい空のウィンドウ
Name[ko]=새 빈 창
Name[ru]=Новое пустое окно
Name[zh_CN]=新建空窗口
Name[zh_TW]=開新空視窗
Exec=/usr/bin/code --disable-gpu --new-window %F
Icon=vscode

NTOE: the global desktop app seems to use /usr/share/code/code, but we need to use /usr/bin/code with --disable-gpu instead according to GPT-5.6-luna told me, because they use different launch behavior. this method works for me!

Update — workaround found (software rendering), root cause still open.

Launching VS Code with --disable-gpu restores the Codex panel on the latest extension
(no rollback needed). We've now seen the blank panel on three Linux machines with different
GPU hardware, and --disable-gpu fixes it on all of them. On one of them the panel had been
blank on every extension version — rollback did NOT help there — so software rendering was the
only thing that fixed it.

Signature on one affected machine (kernel log): traps: Compositor[...] trap invalid opcode
plus SharedImageManager::ProduceMemory ... non-existent mailbox — i.e. the webview renderer's
compositor thread CHECK-crashes while the extension host and app-server stay healthy
(Initialize received id=1). This lines up with the NVIDIA SIGBUS / TransferBuffer::Initialize
reports above: same failure mode, different driver.

The extension update is the trigger, but the defect looks like a Chromium/Electron GPU-rendering
path in the newer webview on some Linux stacks. Consistent with that, the same account's Windows
machines were never affected — this has been Linux-only for us.

Software rendering is a reliable workaround, but a proper fix (the webview avoiding the triggering
GPU features, or the underlying Electron path) would still be very welcome. Leaving this open for that.

For me, --disable-gpu allows it to work in one window only. Opening Codex Settings I get the same issue. If I launch another instance of VSC with the same arg, I get the same issue.

this can maybe be root caused to

vscode/electron

this has to be supported in the framework level,

anyone can track the correct issue within those library to refrence it here?

"window.titleBarStyle": "native"

Then my Codex plugin finally worked again.

"window.titleBarStyle": "native" Then my Codex plugin finally worked again.

I tried a prompt like

https://github.com/openai/codex/issues/32041#issuecomment-5000882242
"window.titleBarStyle": "native"
Then my Codex plugin finally worked again.


trace this to vscode or chromium or electron issue tracker on github

few days ago , I tried to ask LLM (one of the chinese models)
and it suggested me this
https://github.com/microsoft/vscode/issues/311819

whic mentions window.titleBarStyle

@zhang-wenchao What were the steps that help you find the issue?

as of today , it tries link me to this issue , (vscode , is based on electron - which is this weird chromium interface we all know to view VS-CODE like a webbrowser)
https://github.com/electron/electron/issues/27016

who is the blame Vscode or Electron, or codex?

ai web search , tries to link me
https://github.com/electron/electron/issues/27016

WARNING , AI tried to father which issues are the upstream

1. The Direct Upstream Electron Bugs
The Drag Region "Eating" Inputs
Issue: [Electron #1354 — webkit-app-region: drag eats all click events](https://github.com/electron/electron/issues/1354)

The Bug: To make the custom title bar draggable, VS Code utilizes -webkit-app-region: drag. Under Linux, Electron's drag region implementation has long-standing bugs where it aggressively hijacks or fails to release pointer captures. If the drag region coordinates mismatch or fail to update, mouse events never cascade down to adjacent UI elements, leaving them completely unclickable.

Wayland Client-Side Decoration (CSD) Failures
Issue: [Electron #27016 — Add Titlebar support for Wayland](https://github.com/electron/electron/issues/27016)

Issue: [Electron #11907 — Native headerbars / GTK CSD support](https://github.com/electron/electron/issues/11907)

The Bug: These issues trace the structural nightmare of drawing a "custom" title bar on Linux. On macOS and Windows, the OS easily exposes unified frame behaviors. On Linux, Electron has to manually hook into GTK or Ozone/Wayland window protocols to simulate window borders. When these custom hooks misbehave, the application loses its connection to the OS system compositor, triggering focus drops.

2. The Chromium Coordinate Tracker
Issue: [Chromium #1048968 — Frameless window hover and hit-test dropouts](https://www.google.com/search?q=https://bugs.chromium.org/p/chromium/issues/detail%3Fid%3D1048968)

The Bug: Because Electron sits on top of Chromium, it inherits Chromium’s native window hit-testing. Under GNOME and other Linux compositors, when Chromium renders a frameless window, it struggles to recalculate the bounding box coordinates. Hover states and focus vectors become offset or "flicker" out of existence.

3. The Downstream VS Code Traps
Because of these upstream flaws, VS Code’s own issue tracker has numerous reports where the custom title bar breaks the IDE:

Issue: [VS Code #311819 — [Wayland] First keystroke lost after Alt+Tab with custom title bar](https://github.com/microsoft/vscode/issues/311819)

Issue: [VS Code #199535 — Frozen/slow input when switching between windows after inactivity](https://github.com/microsoft/vscode/issues/199535)

The Bug: Users on Linux frequently report that when switching windows or leaving the editor idle, key inputs stop registering. This is because the custom title bar fails to cleanly negotiate window focus with the Linux display server.

Why did this specifically kill Codex?
Codex (like GitHub Copilot, Cursor's chat panels, or any AI assistant plugin) relies on Webviews. Inside the Chromium runtime, Webviews are rendered as isolated, sandboxed sub-processes (iframe overlays).

When you use "window.titleBarStyle": "custom", the upstream bugs in Electron's Linux hit-testing fail to properly calculate the nested boundaries of these Webviews.

The compositor registers that you clicked inside the editor, but Chromium fails to pass the click down into the Webview process boundary.

Because the Webview never receives the click event, it never requests text cursor focus.

The plugin appears completely "frozen" to you, even though the extension process is running flawlessly in the background.

By switching "window.titleBarStyle" to "native", you bypassed Electron's broken custom boundary math. You handed frame and focus management back to your native Linux Window Manager (KWin, Mutter, etc.), which naturally and perfectly routes focus to Chromium, instantly unblocking the Codex input fields.

"window.titleBarStyle": "native" Then my Codex plugin finally worked again.

It stopped working again after a restart half an hour later.

I have now found a truly effective solution: launch it from the command line like this.

ulimit -n 65535 && exec ./code

Several recent issues, whether in VS Code, lower-level components, or the Codex plugin, have all seemed to point indirectly to file descriptor problems.

I simply increased it to the maximum so it can be used for now, then wait for the fix.

> "window.titleBarStyle": "native" > Then my Codex plugin finally worked again. It stopped working again after a restart half an hour later. I have now found a truly effective solution: launch it from the command line like this. ulimit -n 65535 && exec ./code Several recent issues, whether in VS Code, lower-level components, or the Codex plugin, have all seemed to point indirectly to file descriptor problems. I simply increased it to the maximum so it can be used for now, then wait for the fix.

Thank you for the fast respond --- I am wondering if this is a widespread issue - maybe this can be traced to Electron or Vs-Code as you say " VS Code, lower-level components,"

far as I concern it can be a issue with linux-distro misconfiguring wayland (or other part in the link - like the package managers --- or if they use gdm or sddm to boot their WM that uses wayland )

> "window.titleBarStyle": "native" > Then my Codex plugin finally worked again. It stopped working again after a restart half an hour later. I have now found a truly effective solution: launch it from the command line like this. ulimit -n 65535 && exec ./code Several recent issues, whether in VS Code, lower-level components, or the Codex plugin, have all seemed to point indirectly to file descriptor problems. I simply increased it to the maximum so it can be used for now, then wait for the fix.

potentionally maybe someone in the issue tracker of "KDE Plasma" or "gnome" regarding this can have a lead regarding what could it be

Ok guys, I found a 100% reliable workaround and a potentially useful discriminator for this Linux webview startup race:

Workaround

Set the VS Code log level to Trace before the Codex extension/webview is activated, then reload the VS Code window.

Developer: Set Log Level... → Trace
Developer: Reload Window

With Trace configured as the default log level, Codex loads successfully on every tested launch.

Environments tested

Affected:

• Linux Mint desktop PC, native VS Code
• Separate Linux Mint work laptop, native VS Code
• VSCodium on the Linux Mint laptop
• code-server hosted on Ubuntu
• Reproduced with every other extension disabled

Unaffected:

• Windows PC

Controlled results

Baseline:

• Normal startup followed by opening Codex: 0/5 successful
• Enable Trace before opening Codex: 6/6 successful
• Keep Trace as the default and restart VS Code: 3/3 successful

This strongly suggests a timing/concurrency-sensitive initialization bug. Trace logging may alter scheduling or reduce peak concurrency while the webview loads its bundled assets, allowing React / bootstrap initialization to complete...

This also appears consistent with #32420 and #32530, where failing sessions stop before React root render requested / app routes mounted, sometimes alongside local webview resource-loading failures.

Root cause confirmed on my machine: file descriptor exhaustion in the renderer process.

I hit the same symptom on Ubuntu (GNOME Wayland, VS Code 1.129.1, extension 26.715.31925): the Codex sidebar stays blank or stuck on the logo, while the extension host activates normally, codex app-server spawns and initializes successfully, and stays alive.

While the panel was blank, I inspected the VS Code processes directly:

$ grep "open files" /proc/<renderer-pid>/limits
Max open files            1024                 524288               files
$ ls /proc/<renderer-pid>/fd | wc -l
1021

The renderer process hosting the Codex webview was sitting at 1021 of its 1024 soft limit — fully exhausted. The webview loads hundreds of small JS chunks concurrently via Webview.loadLocalResource, which blows past the default Linux soft limit. This matches the insufficient resources service-worker fetch failures and the net::ERR_FAILED asset loads reported in #32530, and the listener-LEAK stack traces through doReadFileStream → loadLocalResource I see in renderer.log.

This also explains why the earlier workarounds (--disable-extension <nonexistent> in #32388, Trace log level) only work intermittently: they merely shift timing/concurrency, so whether you cross the fd ceiling becomes a coin flip. It also explains why Windows is unaffected (no comparable per-process fd soft limit).

Reliable fix (confirmed working across restarts):

1. Launch wrapper: ulimit -n 65535 && exec /usr/share/code/code "$@" (pointed my .desktop file at it), and/or
2. Session-wide: ~/.config/systemd/user.conf.d/99-nofile.conf with [Manager] / DefaultLimitNOFILE=65535:524288 (takes effect after re-login).

After relaunching, all VS Code processes including renderers show a 65535 limit and the Codex panel loads on every start.

Note for anyone verifying: Electron raises the main process limit to 524288 by itself, so checking the main PID is misleading — the zygote/renderer children keep the original 1024 soft limit. Check a --type=renderer process.

Suggested fix on the extension side: throttle/batch the webview asset fetches, or bundle into fewer chunks, so the webview doesn't require thousands of concurrent file descriptors during bootstrap.

Ok guys, I found a 100% reliable workaround and a potentially useful discriminator for this Linux webview startup race: ## Workaround Set the VS Code log level to Trace before the Codex extension/webview is activated, then reload the VS Code window. Developer: Set Log Level... → Trace Developer: Reload Window With Trace configured as the default log level, Codex loads successfully on every tested launch. ## Environments tested Affected: Linux Mint desktop PC, native VS Code Separate Linux Mint work laptop, native VS Code VSCodium on the Linux Mint laptop code-server hosted on Ubuntu Reproduced with every other extension disabled Unaffected: Windows PC ## Controlled results Baseline: Normal startup followed by opening Codex: 0/5 successful Enable Trace before opening Codex: 6/6 successful * Keep Trace as the default and restart VS Code: 3/3 successful This strongly suggests a timing/concurrency-sensitive initialization bug. Trace logging may alter scheduling or reduce peak concurrency while the webview loads its bundled assets, allowing React / bootstrap initialization to complete... This also appears consistent with #32420 and #32530, where failing sessions stop before React root render requested / app routes mounted, sometimes alongside local webview resource-loading failures.

The only thing that helps !!
I had to restart vscode and make sure Trace set before Codex window loads and it works also with multi windows

> Ok guys, I found a 100% reliable workaround and a potentially useful discriminator for this Linux webview startup race: > ## Workaround > Set the VS Code log level to Trace before the Codex extension/webview is activated, then reload the VS Code window. > Developer: Set Log Level... → Trace > Developer: Reload Window > With Trace configured as the default log level, Codex loads successfully on every tested launch. > ## Environments tested > Affected: > > Linux Mint desktop PC, native VS Code > Separate Linux Mint work laptop, native VS Code > VSCodium on the Linux Mint laptop > code-server hosted on Ubuntu > Reproduced with every other extension disabled > > Unaffected: > > Windows PC > > ## Controlled results > Baseline: > > Normal startup followed by opening Codex: 0/5 successful > Enable Trace before opening Codex: 6/6 successful > * Keep Trace as the default and restart VS Code: 3/3 successful > > This strongly suggests a timing/concurrency-sensitive initialization bug. Trace logging may alter scheduling or reduce peak concurrency while the webview loads its bundled assets, allowing React / bootstrap initialization to complete... > This also appears consistent with #32420 and #32530, where failing sessions stop before React root render requested / app routes mounted, sometimes alongside local webview resource-loading failures. The only thing that helps !! I had to restart vscode and make sure Trace set before Codex window loads and it works also with multi windows

has ulimit helped you?
potentionally , I think ibus could have and effect on this ipc thing , if thats the issue
potentianlly on another hand --- maybe changing ulimit within systemd/systemctl/sysctl can actually maybe help here

also how are you launch VSCODE , from flatpak - or your Linux Distroy Packagemanager

can you try
fcitx5 from ibus
https://github.com/microsoft/vscode/issues/311819#issuecomment-5006039377

I cannot replicate it on my machine (Im a Fedora user , on Wayland + systemd )

(warning read what is ibus and fcitx5)
<img width="869" height="648" alt="Image" src="https://github.com/user-attachments/assets/33bfeb2c-090c-4a23-b9fe-79dcecddaae0" />

at the very least even if a ulimit thing - it should not crash like its nothing - because we want to deal with yet more javascript/nodejs bad standards - yet chromium and v8 are very nice likley because it meant for other reasons other than extentions to an electron app --- but you assume - whatever a VSCODE EXTENTION does it will not crash itself -- in a way that isnt traceable and root-caused to anything

we dont know if its flatpak - we dont know if its systemd - we dont know how much ulimit has to do with it - we dont know if its distro related

what do we know? its an Electron issue? a Ulimit issue?
next some users say they have a good time if they are using "--disable-gpu" a chromium/electron flag --- I dont think it has anything to do with vscode - despite vscode should have noticed how to deal with such things over linux

(this snippet is cited from a user above)
4:2026-07-10 09:46:27.893 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed
7:2026-07-10 09:46:27.923 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed
8:2026-07-10 09:46:28.017 [info] [CodexMcpConnection] Initialize received id=1

VS Code renderer sometimes terminates with SIGBUS, and Chromium reports TransferBuffer::Initialize and AllocateRingBuffer failures

explains nothing