What version of the IDE extension are you using?
VS Code 1.118.1, arm64
What subscription do you have?
Enterprise
Which IDE are you using?
VS Code
What platform is your computer?
Darwin 24.6.0 arm64 arm
What issue are you seeing?
The VS Code Codex history/task list intermittently fails to show chats that still exist in the local Codex history store.
The affected chats are still present in the local SQLite state database and have corresponding rollout JSONL transcript files. In at least one case, the chat was also present in session_index.jsonl. Opening the chat by local thread id can recover it, so this appears to be a VS Code history listing/search/indexing issue rather than data loss.
Local data was not lost. The chat existed in:
- ~/.codex/state_5.sqlite
- ~/.codex/sessions/.../rollout-*.jsonl
- ~/.codex/session_index.jsonl
Actual behavior:
- Some chats that exist locally are absent from the VS Code history UI.
- Search/list behavior appears to use a cached or partial thread list.
What steps can reproduce the bug?
The issue is intermittent. I create, switch, and resume several conversations per day.
I do not currently have a deterministic minimal reproduction, but this has happened a couple of times:
- Use Codex in VS Code across many chats in the same workspace.
- Later try to find an older chat from the VS Code Codex history/task list.
- The chat is missing from the VS Code history UI.
- Inspect the local Codex history storage.
- Confirm that the missing chat still exists in state_5.sqlite.
- Confirm that the corresponding rollout JSONL transcript file still exists.
- Optionally confirm whether the chat is also present in session_index.jsonl.
- Open the chat directly by local thread id and confirm it is recoverable.
What is the expected behavior?
If a Codex chat exists in the local SQLite state database, is not archived, belongs to the VS Code source, matches the current workspace, and has a valid rollout JSONL transcript file, it should appear in the VS Code Codex history/task list and be searchable/recoverable from the UI.
The history UI should not depend on a stale or partial recent-chat cache if the authoritative local state still contains matching chats.
Additional information
Environment:
- macOS 15.7.5, build 24G624
- VS Code 1.118.1, arm64
- OpenAI ChatGPT / Codex VS Code extension: openai.chatgpt@26.429.30905
- codex-cli 0.128.0
Local DB counts at the time:
- vscode active: 174
- vscode archived: 8
- cli active: 2
- cli archived: 4
- exec active: 8
The issue seems to involve inconsistency between the authoritative local history data and what the VS Code Codex history UI lists or searches.
What version of the IDE extension are you using?
VS Code 1.118.1, arm64
What subscription do you have?
Enterprise
Which IDE are you using?
VS Code
What platform is your computer?
Darwin 24.6.0 arm64 arm
What issue are you seeing?
The VS Code Codex history/task list intermittently fails to show chats that still exist in the local Codex history store.
The affected chats are still present in the local SQLite state database and have corresponding rollout JSONL transcript files. In at least one case, the chat was also present in session_index.jsonl. Opening the chat by local thread id can recover it, so this appears to be a VS Code history listing/search/indexing issue rather than data loss.
Local data was not lost. The chat existed in:
Actual behavior:
What steps can reproduce the bug?
The issue is intermittent. I create, switch, and resume several conversations per day.
I do not currently have a deterministic minimal reproduction, but this has happened a couple of times:
What is the expected behavior?
If a Codex chat exists in the local SQLite state database, is not archived, belongs to the VS Code source, matches the current workspace, and has a valid rollout JSONL transcript file, it should appear in the VS Code Codex history/task list and be searchable/recoverable from the UI.
The history UI should not depend on a stale or partial recent-chat cache if the authoritative local state still contains matching chats.
Additional information
Environment:
Local DB counts at the time:
The issue seems to involve inconsistency between the authoritative local history data and what the VS Code Codex history UI lists or searches.