Unable to open past conversation history in VS Code extension

What version of the IDE extension are you using?

1.117.0

What subscription do you have?

plus

Which IDE are you using?

vs code

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Recently, I have been unable to open any past conversation records. When I click on a history item in the sidebar, the interface does not respond, and the previous chat content fails to load. There are no explicit error pop-ups, but the chat window remains blank or stuck.

What steps can reproduce the bug?

What steps can reproduce the bug?*
Open VS Code and ensure the GPT Codex extension is logged in.

Click on the "History" icon/tab to view past conversations.

Click on any specific historical conversation title from the list.

Observe that the chat interface does not update or display the selected history.

What is the expected behavior?

What is the expected behavior?
The extension should correctly fetch and display the full chat history of the selected conversation when clicked.

Additional information

No response

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

VS Code extension: Existing chat thread gets stuck only in one workspace until thread receives a new response elsewhere #18963
[extension][Windows][Cursor/Antigravity] Long existing threads open as blank panel while short threads load normally #18931
VS Code: Slow switching between task history #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.

.

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.

.

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.

One eternity later:

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

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)

@metrax

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

same

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

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

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.

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

Disable Codex Extension
Strg+Shift+P > Restart Extension Host and Reload Window
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:
{
  "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.

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

Codex VS Code Blank Webview on Windows 10: Investigation and Fix

I had an issue where the OpenAI Codex VS Code extension opened to a blank dark webview with only the OpenAI logo visible. The Codex panel never reached the sign-in/chat UI.

In my case, the final root cause was not GPU rendering, VS Code cache, VS Code profile state, Codex extension version, or VS Code version. The actual issue was corrupted/broken local Codex state under the user .codex folder, which caused the Codex app-server to crash during startup.

Environment

OS: Windows 10
VS Code: originally 1.131.0
Also tested: VS Code 1.130.0
Codex extension: 26.727.40816
Also tested: two older Codex extension versions

Symptom

The Codex extension page loaded normally in VS Code, but the Codex panel itself opened to a dark blank webview with only the OpenAI logo in the center.

The UI stayed stuck there and never loaded the sign-in/chat screen.

Things I Tried That Did Not Fix It

I first tried the usual extension, webview, and VS Code fixes:

Reloaded VS Code
Disabled and enabled the Codex extension
Restarted the extension
Reinstalled the Codex extension
Disabled GPU / hardware acceleration
Reset VS Code webview/cache/state folders
Reset VS Code workspace storage
Tested with a completely clean VS Code profile using --user-data-dir and --extensions-dir
Installed two older Codex extension versions
Downgraded VS Code from 1.131.0 to 1.130.0

None of those fixed the issue.

Debugging Steps

I checked the webview console using:

Developer: Open Webview Developer Tools

The console showed some VS Code/webview warnings, but they did not clearly explain why Codex was stuck on the logo.

View -> Output -> Codex

Important Error Log

The Codex output log showed that the extension was activating and trying to start the Codex app-server, but the app-server crashed immediately because SQLite state initialization failed under the user .codex directory:

2026-08-05 12:31:50.423 [info] Activating Codex extension
2026-08-05 12:31:50.423 [info] [CodexMcpConnection] Spawning codex app-server
2026-08-05 12:31:50.423 [info] [IpcRouter] I am the router
2026-08-05 12:31:50.423 [warning] [IpcClient] Received broadcast but no handler is configured method=client-status-changed
2026-08-05 12:31:52.135 [error] [CodexMcpConnection] cli: message="Error: failed to initialize sqlite state runtime under C:\Users\<WindowsUser>\.codex: failed to initialize state runtime at C:\Users\<WindowsUser>\.codex"
2026-08-05 12:31:52.148 [error] [CodexMcpConnection] Codex process fatal error errorMessage="Codex process errored: Codex app-server process exited unexpectedly (code=1 (0x1), signal=null). Last CLI error: Error: failed to initialize sqlite state runtime under C:\Users\<WindowsUser>\.codex: failed to initialize state runtime at C:\Users\<WindowsUser>\.codex" exitCode=1 signal=null
2026-08-05 12:31:52.149 [error] [CodexWebviewProvider] Fatal error message="Codex process errored: Codex app-server process exited unexpectedly (code=1 (0x1), signal=null). Last CLI error: Error: failed to initialize sqlite state runtime under C:\Users\<WindowsUser>\.codex: failed to initialize state runtime at C:\Users\<WindowsUser>\.codex"

After that, later logs showed that the webview kept trying to communicate with Codex, but the Codex process was already gone:

[warning] [CodexMcpConnection] Attempted to send app-server message but stdin is destroyed
[error] [CodexMcpConnection] Codex process fatal error errorMessage="Codex process errored: Codex process is not available"
[error] [CodexWebviewProvider] Fatal error message="Codex process errored: Codex process is not available"

Root Cause

The Codex app-server could not initialize its local SQLite state runtime under:

C:\Users\<WindowsUser>\.codex

Because of that, the app-server exited immediately with code 1.

The webview was not the actual root cause. It stayed blank because the backend process it depends on had crashed.

So in my case, the issue was a corrupted, locked, or otherwise unusable Codex local state folder:

C:\Users\<WindowsUser>\.codex

Fix That Worked

I closed VS Code, killed any running Codex process, and renamed the existing .codex folder so Codex could create a fresh one.

Run this in PowerShell:

taskkill /IM Code.exe /F
taskkill /IM codex.exe /F

$old = "$env:USERPROFILE\.codex"
$bak = "$env:USERPROFILE\.codex.bak-$(Get-Date -Format yyyyMMdd-HHmmss)"

Rename-Item -LiteralPath $old -NewName (Split-Path $bak -Leaf)

Then reopen VS Code and open Codex again.

This fixed the blank logo screen immediately for me.

Unable to open past conversation history in VS Code extension #18993

Description

What version of the IDE extension are you using?

What subscription do you have?

Which IDE are you using?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Apr 22, 2026

rafaelsg-01 commented on Apr 23, 2026

ChangeFWorld commented on Apr 23, 2026

alex-jitbit commented on Apr 23, 2026

Kai-Chen00 commented on Apr 23, 2026

YodaEmbedding commented on Apr 23, 2026

NCCYUNSONG commented on Apr 24, 2026

metrax commented on Apr 24, 2026

wajdijurry commented on Apr 24, 2026

benapetr commented on Apr 26, 2026

JosephWamulume commented on Apr 27, 2026

iamhenryhuang commented on Apr 27, 2026

26 remaining items

timohuovinen commented on Jul 1, 2026

cvasilatos commented on Jul 3, 2026

julianofischer commented on Jul 4, 2026

julianofischer commented on Jul 4, 2026

open VS Code terminal

MahooX commented on Jul 6, 2026

env0j commented on Jul 8, 2026

timohuovinen commented on Jul 8, 2026

Codex VS Code Blank Screen

Symptom

What Was Ruled Out

Root Cause

Fix

Verification

Rollback

julianofischer commented on Jul 9, 2026

Codex VS Code Blank Screen

Symptom

What Was Ruled Out

Root Cause

Fix

Verification

Rollback

Tonny24Wang commented on Jul 9, 2026

Dimensione4 commented on Jul 9, 2026

rostidev commented on Jul 11, 2026

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

Dimensione4 commented on Jul 11, 2026

brownbr84 commented on Jul 19, 2026

Codex VS Code Tela em branco

Sintoma

O que foi descartado

Causa raiz

Consertar

Verificação

Reverter

thatsuman commented on Aug 5, 2026

Codex VS Code Blank Webview on Windows 10: Investigation and Fix

Environment

Symptom

Things I Tried That Did Not Fix It

Debugging Steps

Important Error Log

Root Cause

Fix That Worked

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions