VS Code extension silently fails to open older local sessions

Summary

VS Code extension session history sometimes fails silently when opening older local Codex conversations. Clicking a conversation in the extension UI does not open it, but the same session can be resumed successfully from the CLI.

During investigation, the local session data appeared intact, but the extension/app-server logs showed transport overload warnings and the structured log database continued recording high-volume TRACE events despite the app-server being launched with RUST_LOG=warn.

User-visible behavior

1. Open Codex in the VS Code extension.
2. Click an older conversation from session history.
3. Nothing visibly happens in the extension UI.
4. No clear user-facing error is shown.
5. The same conversation can be resumed from the CLI with codex resume <session-id>.

Expected behavior

If the session exists and can be resumed by the CLI, the VS Code extension should either:

• open the conversation successfully, or
• show a clear error explaining why it cannot be opened.

It should not fail silently.

Actual behavior

The extension UI appears to ignore the click or fail silently. The conversation does not open, even though the local rollout/session data is present and the CLI can resume it.

Local findings

The affected session was present in local Codex state:

• rollout file existed under ~/.codex/sessions/...
• thread was present in ~/.codex/state_5.sqlite
• thread was not archived
• CLI resume worked

One local index file, ~/.codex/session_index.jsonl, did not include the affected session even though the SQLite threads table did. I do not know whether the extension relies on this file, but it may be relevant.

The VS Code extension/app-server logs showed repeated transport overload warnings shortly after startup:

codex_app_server::transport: dropping overload response for connection ... outbound queue is full

This may explain the silent UI behavior: if app-server responses are being dropped, the extension may never receive the response needed to hydrate/open the selected conversation.

Logging / state bloat findings

The extension launch path appears to set:

RUST_LOG=warn

However, ~/.codex/logs_2.sqlite continued to collect fresh rows with:

level = TRACE

Recent TRACE targets included:

log
codex_app_server::outgoing_message
codex_api::endpoint::responses_websocket
codex_api::sse::responses
codex_core::tools::registry

Some recent TRACE bodies were low-level events such as:

inotify event ... OPEN ... "ld.so.cache"
inotify event ... OPEN ... "locale.alias"

In the same environment, logs_2.sqlite had grown substantially while the human-facing text log was much smaller. The TRACE volume appears to come from accumulated instrumentation/transport/watcher events, not only from one large conversation.

I cannot prove the SQLite log growth caused the session-history failure, but the combination of:

• silent session-open failure in the extension UI
• CLI resume succeeding
• app-server transport queue overload warnings
• high-volume structured TRACE logging despite RUST_LOG=warn

suggests the extension/app-server may be getting into a degraded local-state or message-queue condition where history clicks fail without surfacing an error.

Environment

• VS Code Remote / VS Code Server on Linux
• Codex VS Code extension version: 26.422.71525
• Extension bundled Codex binary: codex-cli 0.126.0-alpha.8
• Separately installed Codex CLI: codex-cli 0.128.0

Pointing the extension at the separately installed CLI with:

"chatgpt.cliExecutable": "/usr/bin/codex"

appeared to improve the ability to open older conversations, which may indicate a bundled app-server/version compatibility issue. I understand this setting is marked development-only, so I am reporting it as diagnostic evidence rather than a recommended fix.

Minimal inspection commands

python3 - <<'PY'
import sqlite3, pathlib

state = pathlib.Path.home() / ".codex/state_5.sqlite"
con = sqlite3.connect(f"file:{state}?mode=ro", uri=True)
con.row_factory = sqlite3.Row

print("recent threads")
for r in con.execute("""
    select id, rollout_path, datetime(updated_at, 'unixepoch') updated, archived, title
    from threads
    order by updated_at desc
    limit 20
"""):
    print(dict(r))
PY

python3 - <<'PY'
import sqlite3, pathlib

logs = pathlib.Path.home() / ".codex/logs_2.sqlite"
con = sqlite3.connect(f"file:{logs}?mode=ro", uri=True)
con.row_factory = sqlite3.Row

print("by level")
for r in con.execute("""
    select level, count(*) rows, round(sum(estimated_bytes)/1024.0/1024.0,2) mb
    from logs
    group by level
    order by rows desc
"""):
    print(dict(r))

print("latest trace rows")
for r in con.execute("""
    select datetime(ts,'unixepoch') ts, level, target, estimated_bytes,
           substr(feedback_log_body,1,180) body
    from logs
    where level='TRACE'
    order by ts desc, ts_nanos desc
    limit 12
"""):
    print(dict(r))
PY

Questions

• Does the VS Code extension rely on session_index.jsonl, state_5.sqlite, or both when opening older conversations?
• Are app-server outbound queue is full warnings expected to cause dropped UI responses?
• Should logs_2.sqlite be controlled by RUST_LOG, or is it intentionally separate structured telemetry/log capture?
• Is there a supported way to rotate or clear logs_2.sqlite safely?