[BUG] VS Code extension: session history ignores the config directory when `claudeCode.claudeProcessWrapper` is set

The extension is querying ~/.claude/projects while the wrapper writes transcripts under ~/.claude-api/projects. The files remain intact, but the VS Code Insiders list is reading from a different store.

I built the VS Code checks in claude-code-session-recovery (BasedGPT/claude-code-session-recovery). First check the global hidden-session list and the Insiders stores with this read-only audit:

~~~sh
python tools/sessions/audit_vscode_session_surfaces.py \
--projects-dir "$HOME/.claude-api/projects" \
--workspace-dir "$HOME/Library/Application Support/Code - Insiders/User/workspaceStorage" \
--global-state-db "$HOME/Library/Application Support/Code - Insiders/User/globalStorage/state.vscdb"
~~~

The audit prints counts and whether the global hidden-session list overlaps local transcripts; it does not print session IDs or write to either store. If it completes with a hidden-session overlap, stop there because a workspace cache injection cannot override that filter.

If the audit completes without a hidden-session overlap, preview the cache scan:

~~~sh
python tools/sessions/recover_vscode_sessions.py \
--projects-dir "$HOME/.claude-api/projects" \
--workspace-dir "$HOME/Library/Application Support/Code - Insiders/User/workspaceStorage"
~~~

This is a dry run. If it lists the affected sessions as missing from the cache, close VS Code Insiders fully and rerun that command with --apply. It backs up the cache and leaves the JSONL transcripts unchanged. If those sessions are already in the cache, the extension's directory choice is the unresolved part and a cache write will not help.

The tools are in BasedGPT/claude-code-session-recovery, where the audit and cache scan both support explicit Insiders and alternate-config paths.

Hope this helps, if my tools are able to help you, would appreciate a ⭐ :)

Still present in 2.1.289 (darwin-arm64). The discard is unchanged in refreshCliAuthStatus():

J=$.viaProcessWrapper===!1, ...
!J)N={value:void 0};else if(typeof L==="object"&&L!==null&&"configDirectory"in L)N={value:L.configDirectory}

There is a second consequence that we think is worse than the missing history: restored tabs start new sessions. When a window reloads, or VS Code restarts, a panel tab whose session is not in that list does not resume. The webview sends launch_claude without resume, and the log shows Spawning Claude with SDK query function - cwd: …, /path/to/wrapper, resume: undefined. Every open conversation is replaced by an empty one on each restart. The transcripts are intact on disk, and claude --resume <id> in a terminal still finds them.

What we saw, with a wrapper that picks CLAUDE_CONFIG_DIR from the folder a session starts in:

• In our extension logs since we set up the wrapper, every restored tab that resumed was a session that still had an older copy of its transcript in ~/.claude/projects/<slug>/, left over from before the wrapper. No session created after the switch was ever resumed on restore.
• A window gets the environment of the code command that opened it. So when a folder is opened from a terminal where another folder's environment is loaded, the extension host has that folder's CLAUDE_CONFIG_DIR. The list and the restore check then read a third config dir, neither ~/.claude nor the one the wrapper uses.
• await_config_home_request returns at once and the tab still starts fresh, because nothing ever follows the config home under a wrapper.

Requested fix: when claudeCode.claudeProcessWrapper is set, use the configDirectory (or projectsDirectory) reported by claude auth status --json for the session list. That is suggestion 1 above. Restored tabs should also wait for that probe before deciding a session cannot be resumed.

Workaround, for anyone else hitting this:

1. Have the wrapper keep ~/.claude/projects/<slug> as a symlink to $CLAUDE_CONFIG_DIR/projects/<slug> for the directory it starts in. <slug> is the absolute real path with every non-alphanumeric character replaced by -. Windows started from the Dock then list and resume correctly.
2. Open VS Code windows without CLAUDE_CONFIG_DIR in the environment, for example with direnv exec / code ….

Some context on why we run two config dirs at all: we run two Claude Code setups side by side on the same Mac. Regular VS Code uses a personal Claude subscription with the default ~/.claude. VS Code Insiders routes Claude Code through Amazon Bedrock via claudeCode.claudeProcessWrapper, and the wrapper sets CLAUDE_CONFIG_DIR=~/.claude-api so the two logins, settings and transcripts never mix. That's also why the ~/.claude/projects/<slug> symlink above isn't an option for us: it would merge the two stores, and the subscription side would list (and could resume) Bedrock conversations.

Confirmed on 2.1.289 that restore runs through the same list: fF5 resumes a saved tab only if its id is in the session list, otherwise it opens fresh_after_missing_saved. Our Insiders logs from before our workaround show zero restored resumes.

One detail for anyone reading their logs: a panel tab is offered for restore only if its session was updated in the last 10 minutes (AL0 = 600000). After an overnight restart, a blank tab is expected even when the list is correct.

Our workaround, for setups with one alternate config dir per app (not per folder). On macOS, VS Code launched from the Dock or Spotlight copies the login shell's environment into the extension host, and every process an app launches carries __CFBundleIdentifier. A window opened with the code CLI skips the login shell (VSCODE_CLI=1) and takes the calling terminal's environment instead, hence the function. In ~/.zshrc:

if [[ "${__CFBundleIdentifier:-}" == "com.microsoft.VSCodeInsiders" ]]; then
  export CLAUDE_CONFIG_DIR="$HOME/.claude-api"
fi
function code-insiders { CLAUDE_CONFIG_DIR="$HOME/.claude-api" command code-insiders "$@"; }

This needs a full quit and relaunch; Reload Window isn't enough. After that, both the history list and tab restore work, and the regular VS Code side is never touched. It can't do per-folder dirs like martaver's wrapper. The real fix is still suggestion 1: when a wrapper is set, use configDirectory from claude auth status --json.