Unable to open past conversation history in VS Code extension

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

• #18963
• #18931
• #17575

Powered by Codex Action

I had the same issue, but it looks like the chat wasn’t actually lost — it was just loading very slowly.

What happened in my case:

• When I clicked the conversation in the Codex panel, it opened as empty (just like reported here).
• Then I went to the Chat tab instead of Codex.
• When I selected the same conversation there, it opened as a tab at the top (like a file) instead of in the right sidebar.
• In this view, the chat loaded instantly.

Meanwhile, the same conversation in the right sidebar was still empty, but after a few minutes, it eventually loaded there as well.

So it seems like the issue is related to how the chat is rendered in the sidebar vs. when opened as a tab.

<img width="444" height="119" alt="Image" src="https://github.com/user-attachments/assets/e91bcb5d-3c6d-46cf-917c-a8504efd78e1" />
.
<img width="450" height="180" alt="Image" src="https://github.com/user-attachments/assets/7d68dce2-9ed3-4c7f-89c4-41efe3ff38d3" />

I had the same issue, but it looks like the chat wasn’t actually lost — it was just loading very slowly. What happened in my case: When I clicked the conversation in the Codex panel, it opened as empty (just like reported here). Then I went to the Chat tab instead of Codex. When I selected the same conversation there, it opened as a tab at the top (like a file) instead of in the right sidebar. In this view, the chat loaded instantly. Meanwhile, the same conversation in the right sidebar was still empty, but after a few minutes, it eventually loaded there as well. So it seems like the issue is related to how the chat is rendered in the sidebar vs. when opened as a tab. <img alt="Image" width="444" height="119" src="https://private-user-images.githubusercontent.com/101224008/582814237-e91bcb5d-3c6d-46cf-917c-a8504efd78e1.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzY5NjIzODUsIm5iZiI6MTc3Njk2MjA4NSwicGF0aCI6Ii8xMDEyMjQwMDgvNTgyODE0MjM3LWU5MWJjYjVkLTNjNmQtNDZjZi05MTdjLWE4NTA0ZWZkNzhlMS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNDIzJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDQyM1QxNjM0NDVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT00NmMzYmNiMGJlMTE0NjIyYTdkMmUyNGUwN2UyMmM4OTZkYzBiNzQ0ZGQ2NGFkODkwZDhkNzFkZDM1MTZlMjIxJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.5jOmBcE003-qXjDH_2Tjkm2AeqiugPp2oi3Tx6t3v9s"> . <img alt="Image" width="450" height="180" src="https://private-user-images.githubusercontent.com/101224008/582814687-7d68dce2-9ed3-4c7f-89c4-41efe3ff38d3.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzY5NjIzODUsIm5iZiI6MTc3Njk2MjA4NSwicGF0aCI6Ii8xMDEyMjQwMDgvNTgyODE0Njg3LTdkNjhkY2UyLTllZDMtNGM3Zi04OWM0LTQxZWZlM2ZmMzhkMy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNDIzJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDQyM1QxNjM0NDVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0yNmYyZGNkYzRlMDk3ZTFkMGIwYzc2MDYzNzMwOWE4ZTVhNzFjMmQxODE2OTk3NWZjZDEwMzQ4MjE1NDc3MDMwJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.QbBkBuPdr5S1sHfs6__HQ2FSUxrG1AnqA33aRpF4D5Q">

Hi, I wonder how can I open a chat in the chat tab you mentioned?

Same issue in Cursor. Chat not loading from history.

Same issue for me when I use code VScode extentions. I think this issue didn't happend on me in the past. Any idea to fix?

Some sessions load at a glacial rate (minutes–hours). It often says "Loading model" for a bit, too, though even once the model "loads", the screen stays blank for quite some time.

<img width="468" height="385" alt="Image" src="https://github.com/user-attachments/assets/0a791b22-62fd-4695-b06c-c09df34e1af0" />

---

One eternity later:

<img width="465" height="454" alt="Image" src="https://github.com/user-attachments/assets/a2b41054-6198-4802-941e-b958ae6db10c" />

---

Switching to certain chats (even if the chat has a much longer history) is instantaneous:

<img width="461" height="458" alt="Image" src="https://github.com/user-attachments/assets/0cde6cf8-a8b7-46df-b9ce-5d33ac468efd" />

Same. I wonder is it a new problem after the latest update?

I had the same problem with the VS Code Codex extension: older history entries were still listed, but opening them resulted in an empty or stuck chat view.

In my case the actual session files were not empty or lost. The problem was that some older rollout JSONL files contained legacy event types that the current VS Code extension apparently no longer renders correctly, for example:

• custom_tool_call
• custom_tool_call_output
• patch_apply_begin
• patch_apply_end
• web_search_call
• web_search_end

I asked Codex itself to repair the local history. It created backup copies, generated filtered copies of the affected JSONL session files without those legacy event types, added the repaired copies back to ~/.codex/state_5.sqlite and ~/.codex/session_index.jsonl, and then I removed the original broken entries after verifying the repaired ones opened correctly.

This was the prompt that worked well for me:

Some older conversations in the VS Code Codex extension are listed in history but open as blank. Please inspect ~/.codex/state_5.sqlite, ~/.codex/session_index.jsonl, and the JSONL files under ~/.codex/sessions and ~/.codex/archived_sessions. Identify conversations whose rollout JSONL files contain legacy event payload types such as custom_tool_call, custom_tool_call_output, patch_apply_begin, patch_apply_end, web_search_call, or web_search_end. For each affected conversation, create a backup first. Then create a repaired copy of the JSONL file that keeps the normal user/assistant messages, function calls, command outputs, reasoning, task events, and metadata, but removes those legacy event records. Register each repaired copy as a new thread in state_5.sqlite and append it to session_index.jsonl with the same title plus (repaired). After verifying that every affected original has a repaired copy and that the repaired files no longer contain those legacy event types, optionally remove the original broken threads from the active state/index and move their original JSONL files into the backup directory instead of deleting them permanently.

After reloading VS Code (Developer: Reload Window), the repaired conversations opened correctly again.

I had the same problem with the VS Code Codex extension: older history entries were still listed, but opening them resulted in an empty or stuck chat view. In my case the actual session files were not empty or lost. The problem was that some older rollout JSONL files contained legacy event types that the current VS Code extension apparently no longer renders correctly, for example: custom_tool_call custom_tool_call_output patch_apply_begin patch_apply_end web_search_call web_search_end I asked Codex itself to repair the local history. It created backup copies, generated filtered copies of the affected JSONL session files without those legacy event types, added the repaired copies back to ~/.codex/state_5.sqlite and ~/.codex/session_index.jsonl, and then I removed the original broken entries after verifying the repaired ones opened correctly. This was the prompt that worked well for me: > Some older conversations in the VS Code Codex extension are listed in history but open as blank. Please inspect ~/.codex/state_5.sqlite, ~/.codex/session_index.jsonl, and the JSONL files under ~/.codex/sessions and ~/.codex/archived_sessions. > Identify conversations whose rollout JSONL files contain legacy event payload types such as custom_tool_call, custom_tool_call_output, patch_apply_begin, patch_apply_end, web_search_call, or web_search_end. > For each affected conversation, create a backup first. Then create a repaired copy of the JSONL file that keeps the normal user/assistant messages, function calls, command outputs, reasoning, task events, and metadata, but removes those legacy event records. Register each repaired copy as a new thread in state_5.sqlite and append it to session_index.jsonl with the same title plus (repaired). > After verifying that every affected original has a repaired copy and that the repaired files no longer contain those legacy event types, optionally remove the original broken threads from the active state/index and move their original JSONL files into the backup directory instead of deleting them permanently. After reloading VS Code (Developer: Reload Window), the repaired conversations opened correctly again.

It worked for me. Thanks

Hello, I have this problem too and from output it seems that it is happening when repo is not github hosted, I can see this:

2026-04-26 22:07:33.819 [error] Error fetching httpStatus=400 requestId=redacted statusText="Bad Request" url=/wham/environments/by-repo/github/redacted/redacted
2026-04-26 22:07:35.342 [info] [git-repo-watcher] Starting git repo watcher
2026-04-26 22:07:35.422 [info] [git-repo-watcher] Starting git repo watcher
2026-04-26 22:07:39.557 [info] [git-repo-watcher] Starting git repo watcher
2026-04-26 22:07:39.617 [info] [git-repo-watcher] Starting git repo watcher
2026-04-26 22:07:39.701 [warning] [IpcClient] Received broadcast but no handler is configured method=query-cache-invalidate
2026-04-26 22:07:39.989 [error] Error fetching httpStatus=403 requestId=redacted statusText=Forbidden url=https://chatgpt.com/ces/v1/rgstr?k=client-redacted&st=javascript-client-react&sv=3.32.2&t=1777234059813&sid=redacted&ec=1&gz=1

Multiple times - this project is hosted on private git server not github, but codex for some reason has "url=/wham/environments/by-repo/github/" when looking up some resource (perhaps the context)

Anyone have a solution for this? I attempted @metrax's solution but I didn't work consistently. The same issue still persists

same

Same issue.
Cursor and VS Code - working on a remote server.

Edit: Switching to pre-release version and reload fixed it temporary.
Later switched back to current version after issue occured again.

Edit: Using cursor now.

Similar to @metrax, I copied this whole github issue page you are on now into codex and said:
"read this github issue. i have the same issue trying to open the 'Review SFM pipelines readiness' convo wth codex. how can i fix in the easiest way?"

Codex inspected my local ~/.codex history, found the affected thread, made a backed-up repaired copy of the JSONL without the legacy event records, registered it as a new repaired thread, and fixed the local history/index metadata.

After that I ran Developer: Reload Window from the VS Code command palette, and the repaired conversation appeared in history.

Hopefully if you give CODEX this full github issue page including my comment here it can also fix it for you.

Codex is being extremely clunky for me. I have to cast magic spells to convince it to load a previous session and half the time it completely deadlocks when attempting to send a follow-up message.

Similar to @metrax, I copied this whole github issue page you are on now into codex and said: "read this github issue. i have the same issue trying to open the 'Review SFM pipelines readiness' convo wth codex. how can i fix in the easiest way?" Codex inspected my local ~/.codex history, found the affected thread, made a backed-up repaired copy of the JSONL without the legacy event records, registered it as a new repaired thread, and fixed the local history/index metadata. After that I ran Developer: Reload Window from the VS Code command palette, and the repaired conversation appeared in history. Hopefully if you give CODEX this full github issue page including my comment here it can also fix it for you.

Thanks Ben,It really works by your steps

I had the same issue, but it looks like the chat wasn’t actually lost — it was just loading very slowly. What happened in my case: When I clicked the conversation in the Codex panel, it opened as empty (just like reported here). Then I went to the Chat tab instead of Codex. When I selected the same conversation there, it opened as a tab at the top (like a file) instead of in the right sidebar. In this view, the chat loaded instantly. Meanwhile, the same conversation in the right sidebar was still empty, but after a few minutes, it eventually loaded there as well. So it seems like the issue is related to how the chat is rendered in the sidebar vs. when opened as a tab. <img alt="Image" width="444" height="119" src="https://private-user-images.githubusercontent.com/101224008/582814237-e91bcb5d-3c6d-46cf-917c-a8504efd78e1.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzczOTI1OTcsIm5iZiI6MTc3NzM5MjI5NywicGF0aCI6Ii8xMDEyMjQwMDgvNTgyODE0MjM3LWU5MWJjYjVkLTNjNmQtNDZjZi05MTdjLWE4NTA0ZWZkNzhlMS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNDI4JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDQyOFQxNjA0NTdaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1mYjY4MWU2NzJkNTlkMWZhMzU3ZmFiMjQzNjYyYzA4Yjc2N2YzMDQ0MjhlMWRkZDdhODg4OWQ2MDllNThkMjNiJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.g6LJTScbzfiB6t-ZzDp_NhOXOOxu6-1MYjBmGxh1Uww"> . <img alt="Image" width="450" height="180" src="https://private-user-images.githubusercontent.com/101224008/582814687-7d68dce2-9ed3-4c7f-89c4-41efe3ff38d3.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzczOTI1OTcsIm5iZiI6MTc3NzM5MjI5NywicGF0aCI6Ii8xMDEyMjQwMDgvNTgyODE0Njg3LTdkNjhkY2UyLTllZDMtNGM3Zi04OWM0LTQxZWZlM2ZmMzhkMy5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNDI4JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDQyOFQxNjA0NTdaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT03OWRjZjIxMGNkMTJkZTUwM2QxMTRlMDIyZWQ0YTE4ODBlNTgwMzg1NjQ0NDFmNzI1OTY0ZjkzNjc2YmRlZTc2JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.SHLJ7Jg0zodr-roOQ9r6J_HO8MlsbvnETiD6CY_icTk">

I confirm this workaround.

Temp fix:

• Open VSCode extensions.
• Disable Codex.
• Click Restart extensions.
• Close + Reopen your Window.
• Enable Codex.

Temp fix: Open VSCode extensions. Disable Codex. Click Restart extensions. Close + Reopen your Window. * Enable Codex.

i have got this annoy issue many days ago, but until now it has not been fixed. I tried this work around, it works back. Thank you

Temp fix: Open VSCode extensions. Disable Codex. Click Restart extensions. Close + Reopen your Window. * Enable Codex.

not working for me

I noticed that in Codex CLI, conversation history opens normally. And for me, it turned out to be even more convenient than VS Code extension.

I changed my permission from full to default then it loaded. try changing permissions

Temp fix: Open VSCode extensions. Disable Codex. Click Restart extensions. Close + Reopen your Window. * Enable Codex.

Worked for me. thanks!

Temp fix: Open VSCode extensions. Disable Codex. Click Restart extensions. Close + Reopen your Window. * Enable Codex.

This is dumb, but it works. Also just disabling and enabling helped.

<img width="659" height="1063" alt="Image" src="https://github.com/user-attachments/assets/38bc8f5a-0392-4667-9439-4999b5f3c665" />

I used the method above, It still doesn't work.

Same for me, it still doesn't work

I solved this by installing another previous version, and reload the window

<img alt="Image" width="659" height="1063" src="https://private-user-images.githubusercontent.com/225983742/596958964-38bc8f5a-0392-4667-9439-4999b5f3c665.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Nzk1OTAwNjgsIm5iZiI6MTc3OTU4OTc2OCwicGF0aCI6Ii8yMjU5ODM3NDIvNTk2OTU4OTY0LTM4YmM4ZjVhLTAzOTItNDY2Ny05NDM5LTQ5OTliNWYzYzY2NS5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNTI0JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDUyNFQwMjI5MjhaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1iMDAyODYxOGYzODU3ZmIyNDk2YTdjYmMwNjU4ZDdkZWM1ZTBmOGE5ZjQ0OTg3OWQ2NjZhYTE1ZGEwMmY5ZTM3JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.fzX8emkwbwCB1mnKUYUJL4HqyH3yP2qCLiPCSCV1Bzk"> I used the method above, It still doesn't work.

does anyone solve it?

Can someone please look at this? Bit ridiculous such a fundamental issue has been open for so long. Happens almost half of the time I open my laptop in the morning and often resulting in needing to completely restart VSCode. At this point, I'm considering switching back to copliot or claude subscription.

<img width="544" height="1027" alt="Image" src="https://github.com/user-attachments/assets/b6b55e50-2577-4ed1-a24a-7af434f9c6dc" />

Mine is completely empty, even with the version before or a version some weeks ago, after updating vscode itself.

<img width="440" height="995" alt="Image" src="https://github.com/user-attachments/assets/bbae4531-22ac-4041-adae-82372fd2804d" />

This is also happening to me, tried to disable -> restart VS Code -> Re-enable it and it still occurs. Even tried uninstalling and re-installing and it's the same issue.

The work around that fixes things for me is

 > rm ~/.codex/logs_2.sqlite*

but yes, really annoying and would be good if someone took the time to address this..

I’ve tried multiple versions of the Codex plugin and VS Code, and also installed Codex plugin on Cursor and Windsurf.In the end, I found that VS Code versions 1.117 and newer fail to load Codex chat properly: builds 118, 120 and 121 work intermittently, while it is completely broken from 124 . 1.116 works well. Maybe it is a bug of VS Code.
I dont know why it is. But hope someone can advise the vscode official to fix the bug.

The work around that fixes things for me is `` > rm ~/.codex/logs_2.sqlite* `` but yes, really annoying and would be good if someone took the time to address this..

this worked for me

I’ve tried multiple versions of the Codex plugin and VS Code, and also installed Codex plugin on Cursor and Windsurf.In the end, I found that VS Code versions 1.117 and newer fail to load Codex chat properly: builds 118, 120 and 121 work intermittently, while it is completely broken from 124 . 1.116 works well. Maybe it is a bug of VS Code. I dont know why it is. But hope someone can advise the vscode official to fix the bug.

<img width="1942" height="742" alt="Image" src="https://github.com/user-attachments/assets/4de98c9c-f8b6-4e9c-a476-ae2d499ae755" />
Today, i found maybe this plugin cause this bug, uninstall it and Codex plugin works well with vscode 1.125(latest version)

open VS Code terminal
------------------------------------
ls -la ~/.codex
ls -l ~/.codex/logs_2.sqlite*

sudo chown -R "$USER:$(id -gn)" ~/.codex
chmod -R u+rwX ~/.codex

rm -f ~/.codex/logs_2.sqlite*

after close vscode and reopen

## open VS Code terminal ls -la ~/.codex ls -l ~/.codex/logs_2.sqlite sudo chown -R "$USER:$(id -gn)" ~/.codex chmod -R u+rwX ~/.codex rm -f ~/.codex/logs_2.sqlite after close vscode and reopen

It worked for me, thanks!

The problem is still not gone, deleting logs workaround sometimes doesn't work

<img width="709" height="1081" alt="Image" src="https://github.com/user-attachments/assets/e8b265c6-24ec-45b7-82e4-25caee569c1c" />

Same issue..again deleting .codex folder does not work either..

<img width="583" height="1016" alt="Image" src="https://github.com/user-attachments/assets/c6d6944b-baac-4920-a12a-f7a7f0698c35" />

very frustrating
I've tried the workarounds here and they don´t work.

## open VS Code terminal ls -la ~/.codex ls -l ~/.codex/logs_2.sqlite sudo chown -R "$USER:$(id -gn)" ~/.codex chmod -R u+rwX ~/.codex rm -f ~/.codex/logs_2.sqlite after close vscode and reopen

well, this worked.
thanks

# 3. 清掉插件 marketplace 缓存
rm -rf ~/.codex/.tmp/plugins
rm -rf ~/.codex/plugins/cache

# 4. 清掉临时目录
rm -rf ~/.codex/.tmp

# 5. 清掉 SQLite 临时锁文件
find ~/.codex -type f \( \
  -name "*.sqlite-wal" -o \
  -name "*.sqlite-shm" -o \
  -name "*.db-wal" -o \
  -name "*.db-shm" \
\) -delete

This worked for me.

I’ve tried all of the methods mentioned above, including clearing the cache and so on. This approach works when I use VS Code locally, but it stops working when I connect to the server via the VS Code SSH extension. The Codex on my server side still remains unresponsive.

After removing the logs_2.sqlite* files doing this fixed it for me:

1. Disable Codex Extension
2. Strg+Shift+P > Restart Extension Host and Reload Window
3. Enable Codex Extension again (+ Reload Window)

I was having that issue in linux ubunutu, but maybe applicable for windows.

After reinstalling vscode and all of codex with all cache clearing, it still didn't work, so after an hour of debugging with Fable and failing and then another hour of debugging with codex cli, I managed to fix it, quoting what it outputted:

# Codex VS Code Blank Screen Date: 2026-07-08 ## Symptom The OpenAI Codex VS Code extension opened to a blank dark webview with only the OpenAI logo visible. The Codex panel also showed an odd horizontal scrollbar at the bottom. This happened on a fresh VS Code install with only openai.chatgpt@26.623.141536 installed. ## What Was Ruled Out - VS Code extension conflicts: code --list-extensions --show-versions showed only openai.chatgpt@26.623.141536. - Codex CLI/auth failure: the bundled CLI at /home/th/.vscode/extensions/openai.chatgpt-26.623.141536-linux-x64/bin/linux-x86_64/codex started successfully outside the VS Code webview and reported idle. - Official Codex docs did not document this exact blank-logo webview state. - The extension host did start Codex successfully: - Activating Codex extension - [CodexMcpConnection] Spawning codex app-server - [CodexMcpConnection] Initialize received id=1 ## Root Cause This was a VS Code/Electron rendering issue, not a Codex account or extension-state issue. The running VS Code process was using the Wayland/Chromium GPU rendering path. After forcing software rendering, the Codex webview loaded normally. The key observed change after restart was that VS Code launched with flags like: - --use-gl=disabled - --disable-gpu-compositing The warning about ~/.codex/.tmp/plugins/plugins/ngs-analysis/.codex-plugin/plugin.json was unrelated. It was only a plugin manifest validation warning and did not prevent the Codex app server from initializing. ## Fix Edit /home/th/.vscode/argv.json and enable hardware acceleration disablement: ``jsonc { "disable-hardware-acceleration": true, "ozone-platform": "x11", "enable-crash-reporter": true, "crash-reporter-id": "321b7146-3f89-42a7-97e2-25f1a4e35f72" } ` Then fully restart VS Code. The important setting was: `jsonc "disable-hardware-acceleration": true ` "ozone-platform": "x11" was also added as a Wayland workaround attempt, but the process list still showed --ozone-platform=wayland; the confirmed effective part was GPU/software rendering disablement. ## Verification After restart, the Codex panel loaded instead of staying on the blank logo screen. Fresh logs still showed the extension and app-server initializing, but the webview rendered correctly. ## Rollback If this causes unrelated VS Code rendering or performance problems, revert /home/th/.vscode/argv.json by commenting out or removing: `jsonc "disable-hardware-acceleration": true, "ozone-platform": "x11", `` Then restart VS Code.

I was having that issue in linux ubunutu, but maybe applicable for windows. After reinstalling vscode and all of codex with all cache clearing, it still didn't work, so after an hour of debugging with Fable and failing and then another hour of debugging with codex cli, I managed to fix it, quoting what it outputted: > # Codex VS Code Blank Screen > Date: 2026-07-08 > ## Symptom > The OpenAI Codex VS Code extension opened to a blank dark webview with only the OpenAI logo visible. The Codex panel also showed an odd horizontal scrollbar at the bottom. This happened on a fresh VS Code install with only openai.chatgpt@26.623.141536 installed. > ## What Was Ruled Out > > VS Code extension conflicts: code --list-extensions --show-versions showed only openai.chatgpt@26.623.141536. > Codex CLI/auth failure: the bundled CLI at /home/th/.vscode/extensions/openai.chatgpt-26.623.141536-linux-x64/bin/linux-x86_64/codex started successfully outside the VS Code webview and reported idle. > Official Codex docs did not document this exact blank-logo webview state. > The extension host did start Codex successfully: > > Activating Codex extension > [CodexMcpConnection] Spawning codex app-server > [CodexMcpConnection] Initialize received id=1 > > ## Root Cause > This was a VS Code/Electron rendering issue, not a Codex account or extension-state issue. > The running VS Code process was using the Wayland/Chromium GPU rendering path. After forcing software rendering, the Codex webview loaded normally. The key observed change after restart was that VS Code launched with flags like: > > --use-gl=disabled > * --disable-gpu-compositing > > The warning about ~/.codex/.tmp/plugins/plugins/ngs-analysis/.codex-plugin/plugin.json was unrelated. It was only a plugin manifest validation warning and did not prevent the Codex app server from initializing. > ## Fix > Edit /home/th/.vscode/argv.json and enable hardware acceleration disablement: > { > "disable-hardware-acceleration": true, > "ozone-platform": "x11", > "enable-crash-reporter": true, > "crash-reporter-id": "321b7146-3f89-42a7-97e2-25f1a4e35f72" > } > > > Then fully restart VS Code. > The important setting was: > "disable-hardware-acceleration": true > > > > > > > > > > "ozone-platform": "x11" was also added as a Wayland workaround attempt, but the process list still showed --ozone-platform=wayland; the confirmed effective part was GPU/software rendering disablement. > ## Verification > After restart, the Codex panel loaded instead of staying on the blank logo screen. Fresh logs still showed the extension and app-server initializing, but the webview rendered correctly. > ## Rollback > If this causes unrelated VS Code rendering or performance problems, revert /home/th/.vscode/argv.json by commenting out or removing: > "disable-hardware-acceleration": true, > "ozone-platform": "x11", > > > > > > > > > > Then restart VS Code.

Thanks.
It was suddenly happening here again and these changes worked.

it works for me !
newest codex plugin！
版本: 1.127.0
提交: 4fe60c8b1cdac1c4c174f2fb180d0d758272d713
日期: 2026-06-30T10:52:33+02:00
Electron: 42.2.0
ElectronBuildId: 14159160
Chromium: 148.0.7778.97
Node.js: 24.15.0
V8: 14.8.178.14-electron.0
OS: Linux x64 6.17.0-35-generic

After installing an other version of Codex (not the lastest), it works for me. Easy peasy lemon squeezyy ;)

Please reopen this issue again, because it still happens to me.

I tries the workaround with "disable-hardware-acceleration": true, and "ozone-platform": "x11", in the ~/.vscode/argv.json file, but it doesn't help. Most of the time Codex can't start properly in my VS Code, but sometimes it can. Seems like a race condition or something like that.

I use Fedora 44 Linux with the proprietary 580xx NVIDIA drivers from RPM Fusion. My desktop environment is Cinnamon under X11 (Wayland isn't officially supported by Cinnamon as yet).

akmod-nvidia-580xx.x86_64                            3:580.173.02-1.fc44                 rpmfusion-nonfree-updates-testing
kmod-nvidia-580xx-7.1.3-200.fc44.x86_64.x86_64       3:580.173.02-1.fc44                 @commandline
libva-nvidia-driver.x86_64                           0.0.17-1.fc44                       updates
nvidia-gpu-firmware.noarch                           20260622-1.fc44                     updates
nvidia-modprobe.x86_64                               3:595.80-1.fc44                     rpmfusion-nonfree-updates
nvidia-persistenced.x86_64                           3:595.80-1.fc44                     rpmfusion-nonfree-updates
nvidia-settings-580xx.x86_64                         3:580.173.02-1.fc44                 rpmfusion-nonfree-updates-testing
xorg-x11-drv-nvidia-580xx.x86_64                     3:580.173.02-1.fc44                 rpmfusion-nonfree-updates-testing
xorg-x11-drv-nvidia-580xx-cuda.x86_64                3:580.173.02-1.fc44                 rpmfusion-nonfree-updates-testing
xorg-x11-drv-nvidia-580xx-cuda-libs.x86_64           3:580.173.02-1.fc44                 rpmfusion-nonfree-updates-testing
xorg-x11-drv-nvidia-580xx-kmodsrc.x86_64             3:580.173.02-1.fc44                 rpmfusion-nonfree-updates-testing
xorg-x11-drv-nvidia-580xx-libs.x86_64                3:580.173.02-1.fc44                 rpmfusion-nonfree-updates-testing
xorg-x11-drv-nvidia-580xx-power.x86_64               3:580.173.02-1.fc44                 rpmfusion-nonfree-updates-testing
xorg-x11-drv-nvidia-580xx-xorg-libs.x86_64           3:580.173.02-1.fc44                 rpmfusion-nonfree-updates-testing

My hardware:

CPU: Intel Xeon W-2135
RAM: 128 GB

GPU: GP107GL [Quadro P1000]
VRAM: 4 GB

I use the latest version of VS Code, installed from the official Microsoft RPM repository:

Version: 1.128.0
Commit: fc3def6774c76082adf699d366f31a557ce5573f
Date: 2026-07-07T15:14:24-07:00
Electron: 42.5.0
ElectronBuildId: 14525058
Chromium: 148.0.7778.271
Node.js: 24.17.0
V8: 14.8.178.33-electron.0
OS: Linux x64 7.1.3-200.fc44.x86_64

Try installing an other version of Codex (not the lastest) in the Extensions of VS code, it works for me. Easy peasy lemon squeezyy ;)

Eu estava tendo esse problema no Linux Ubuntu, mas talvez seja aplicável também ao Windows. Após reinstalar o VS Code e todo o Codex, limpando o cache, o problema persistiu. Depois de uma hora depurando com o Fable sem sucesso e mais uma hora depurando com o Codex CLI, finalmente consegui resolver. Segue abaixo a saída do comando: > # Codex VS Code Tela em branco > Data: 08/07/2026 > ## Sintoma > A extensão OpenAI Codex para VS Code abriu em uma visualização da web escura e em branco, com apenas o logotipo da OpenAI visível. O painel do Codex também exibia uma barra de rolagem horizontal estranha na parte inferior. Isso ocorreu em uma instalação limpa do VS Code com apenas openai.chatgpt@26.623.141536a extensão instalada. > ## O que foi descartado > > Conflitos de extensões do VS Code: code --list-extensions --show-versionsapenas openai.chatgpt@26.623.141536. > Falha na autenticação/CLI do Codex: a CLI incluída foi /home/th/.vscode/extensions/openai.chatgpt-26.623.141536-linux-x64/bin/linux-x86_64/codexiniciada com sucesso fora da visualização da web do VS Code e relatou estar ociosa. > A documentação oficial do Codex não registrou esse estado exato de visualização da web com o logotipo em branco. > O host da extensão iniciou o Codex com sucesso: > > Activating Codex extension > [CodexMcpConnection] Spawning codex app-server > [CodexMcpConnection] Initialize received id=1 > > ## Causa raiz > Este era um problema de renderização do VS Code/Electron, não um problema com a conta do Codex ou com o estado da extensão. > O processo do VS Code em execução estava usando o caminho de renderização por GPU Wayland/Chromium. Após forçar a renderização por software, a visualização da web do Codex carregou normalmente. A principal mudança observada após a reinicialização foi que o VS Code foi iniciado com parâmetros como: > > --use-gl=disabled > * --disable-gpu-compositing > > O aviso ~/.codex/.tmp/plugins/plugins/ngs-analysis/.codex-plugin/plugin.jsonnão tinha relação com o assunto. Era apenas um aviso de validação do manifesto do plugin e não impedia a inicialização do servidor de aplicativos do Codex. > ## Consertar > Edite /home/th/.vscode/argv.jsone ative a desativação da aceleração de hardware: > { > "disable-hardware-acceleration": true, > "ozone-platform": "x11", > "enable-crash-reporter": true, > "crash-reporter-id": "321b7146-3f89-42a7-97e2-25f1a4e35f72" > } > > > > > > > > > > Em seguida, reinicie completamente o VS Code. > O contexto importante era: > "disable-hardware-acceleration": true > > > > > > > > > > "ozone-platform": "x11"Também foi adicionado como uma tentativa de solução alternativa para o Wayland, mas a lista de processos ainda mostrava --ozone-platform=wayland; a parte que se mostrou eficaz foi a desativação da renderização por GPU/software. > ## Verificação > Após a reinicialização, o painel do Codex carregou em vez de permanecer na tela em branco com o logotipo. Os registros atualizados ainda mostravam a extensão e o servidor de aplicativos sendo inicializados, mas a visualização da web era renderizada corretamente. > ## Reverter > Se isso causar problemas não relacionados de renderização ou desempenho no VS Code, reverta /home/th/.vscode/argv.jsoncomentando ou removendo a seguinte linha: > "disable-hardware-acceleration": true, > "ozone-platform": "x11", > > > > > > > > > > Em seguida, reinicie o VS Code.

Muito bom, aqui funcionou no win