[BUG]

Status Open
Reported on v2.1.259
Maintainer reply None cached
Activity 0 comments · opened Sep 3, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

VS Code extension deletes ~/.claude/.credentials.json seconds after login — signs out the CLI too

Summary

On Windows 11, the Claude Code VS Code extension's bundled claude.exe deletes
%USERPROFILE%\.claude\.credentials.json within ~10–20 seconds of a successful login.
Because the CLI reads that same file, every Claude Code surface on the machine is signed
out at once. Logging in again produces another deletion within seconds, so the panel is
unusable.

I confirmed the deleting process with Windows Security-log file auditing (event 4660),
which names the deleting PID and image path at the kernel level. The deleting binary is
always the extension's own:

C:\Users\walke\.vscode\extensions\anthropic.claude-code-<version>-win32-x64\resources\native-binary\claude.exe

Reproduced on three extension versions: 2.1.259, 2.1.258, and 2.1.121. Since 2.1.121
is ~138 versions older, this does not appear to be a recent regression.

Environment

| | |
|---|---|
| OS | Windows 11 Pro 10.0.26200 |
| VS Code | 1.136.0 |
| Extension | anthropic.claude-code 2.1.259, 2.1.258, 2.1.121 (all affected) |
| CLI | 2.1.259, native install at ~\.local\bin\claude.exe |
| Account | Max 20x, single account, organizationRole: admin |
| Auth | OAuth only — no ANTHROPIC_API_KEY, no apiKeyHelper, no customApiKeyResponses |

Steps to reproduce

  1. Sign in to Claude Code (either surface); ~/.claude/.credentials.json is written.
  2. Open the Claude Code panel in VS Code and interact with it.
  3. Within ~10–20 seconds the credentials file is deleted. The panel shows a sign-in

prompt and any running CLI session reports "Not logged in · Please run /login".

  1. Sign in again — the file is deleted again, usually within seconds.

An idle panel does not appear to trigger it; panel activity (typing, or the panel
spawning its per-request claude.exe) does.

Evidence: audited deletions

Windows file auditing (SACL on ~\.claude, auditpol Object Access → File System)
recorded these. Each line is event 4660 correlated to its 4656/4663 by HandleId:

20:30:08.017   PID 1968    ...anthropic.claude-code-2.1.259-win32-x64\...\claude.exe
20:30:29.633   PID 38240   ...anthropic.claude-code-2.1.259-win32-x64\...\claude.exe
20:41:38.610   PID 1804    ...anthropic.claude-code-2.1.258-win32-x64\...\claude.exe
20:42:01.053   PID 24540   ...anthropic.claude-code-2.1.258-win32-x64\...\claude.exe
20:46:50.157   PID 4480    ...anthropic.claude-code-2.1.121-win32-x64\...\claude.exe

Target file in every case: C:\Users\walke\.claude\.credentials.json

Two properties worth noting:

  • The deleting PIDs are short-lived spawns. None of 1968, 38240, 1804, 24540, or 4480

appear in a process listing captured a fraction of a second later. The panel spawns a
claude.exe, it deletes the file, it exits.

  • A polling watcher that only lists running processes cannot catch this — by the time

it samples, the culprit is gone. This is likely why the failure has been hard to
attribute.

Two distinct deletion paths

Path A — server-side revocation (logged). One occurrence had a clear cause in the
extension log:

19:52:48.253  webview → io_message                    (user submits a message)
19:52:48.314  [API REQUEST] /v1/messages source=sdk
19:52:48.419  [ERROR] API error 401
              {"type":"authentication_error",
               "message":"OAuth access token has been revoked."}
19:52:48.436  Getting authentication status → No authentication found
19:52:48.618  credentials file gone

The revoked token had authenticated a successful call 22 seconds earlier:

19:52:25   panel login completes, credentials written
19:52:26.7 fetchUtilization: GET /api/oauth/usage → 200 after 1 attempt(s)
19:52:48.4 same token → /v1/messages → 401 revoked

Client request IDs from that failure: 4915d1f7-e3b3-4900-9dd8-c5d68d8219cc,
f1a12460-37f4-46b2-8910-43c2daade0b6.

Path B — silent deletion (not logged). Most deletions have no 401, no error, no
logout request, and no user message anywhere in the extension log. Example at 20:12:07:
a panel process started at 20:11:46, and 21 seconds later the file was gone with
grep -c "401|revoked|logout|io_message" returning 0 for that window. Path B is the
common case.

Expected vs actual

Expected: an auth failure in the VS Code panel should, at most, sign out the panel,
and only after a real credential failure. A revoked-token 401 on one request should not
delete the shared credential store used by other processes.

Actual: the panel's bundled binary deletes the shared credentials file — in the common
case with no logged error at all — signing out the CLI and any other running session on
the machine.

Impact

  • The VS Code panel cannot be used; it signs itself out within seconds of each login.
  • Collateral damage to the CLI: unrelated terminal sessions lose auth mid-task, because

both surfaces read ~/.claude/.credentials.json.

  • Users cannot work around it at the login prompt — the deletion is faster than a login.

Things ruled out during investigation

| Hypothesis | Ruled out by |
|---|---|
| Version mismatch panel vs CLI | Both 2.1.259; also reproduced on 2.1.258 and 2.1.121 |
| Recent regression | 2.1.121 (~138 versions older) is affected |
| Stale second-account token | Second config dir moved aside; behavior unchanged |
| A second credential store (Credential Manager / state.vscdb) | No Anthropic entries in either; extension reads claudeAiOauth from .credentials.json |
| CLI/panel race over the file | A deletion occurred with only panel processes running, no CLI |
| Desktop app interference | Desktop app authenticates to its own sandboxed store (AppData\Local\Packages\Claude_pzs8sxrjxfjjc); its login left .credentials.json byte-identical |
| Malformed credential | Token has full scopes (user:profile user:inference user:mcp_servers user:sessions:claude_code user:file_upload); a healthy in-place refresh was observed at 20:42:34 |
| Env-var / API-key precedence | No ANTHROPIC_API_KEY, no apiKeyHelper, no customApiKeyResponses, no machine/user env overrides |

Workaround

Disable the VS Code extension and use the CLI. Credentials persist indefinitely when no
panel process is running.

Suggested fix

Narrow the conditions under which the credential store is deleted:

  1. Don't delete shared credentials on a 401 from a single API request. Attempt a refresh

first; only clear on a definitive refresh-token failure (e.g. invalid_grant).

  1. Log every deletion of .credentials.json with the reason, at INFO. Path B currently

leaves no trace, which makes this effectively undiagnosable without OS-level auditing.

  1. Consider whether a per-surface credential invalidation is possible, so a panel-side auth

failure doesn't sign out unrelated CLI sessions sharing the file.

Reproduction tooling

If useful, the audit setup that produced the attribution above:

# elevated, once
auditpol /set /subcategory:"File System" /success:enable /failure:enable
$acl = Get-Acl "$env:USERPROFILE\.claude" -Audit
$acl.AddAuditRule((New-Object System.Security.AccessControl.FileSystemAuditRule(
  "Everyone","Delete,DeleteSubdirectoriesAndFiles","ObjectInherit","NoPropagateInherit","Success,Failure")))
Set-Acl "$env:USERPROFILE\.claude" $acl

# then correlate 4660 (delete) back to 4656/4663 (open/access) by HandleId
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4656,4660,4663;StartTime=(Get-Date).AddMinutes(-15)}

What Should Happen?

Claude Code Extension should work as advertised

Error Messages/Logs

Steps to Reproduce

VS Code extension deletes ~/.claude/.credentials.json seconds after login — signs out the CLI too

Summary

On Windows 11, the Claude Code VS Code extension's bundled claude.exe deletes
%USERPROFILE%\.claude\.credentials.json within ~10–20 seconds of a successful login.
Because the CLI reads that same file, every Claude Code surface on the machine is signed
out at once. Logging in again produces another deletion within seconds, so the panel is
unusable.

I confirmed the deleting process with Windows Security-log file auditing (event 4660),
which names the deleting PID and image path at the kernel level. The deleting binary is
always the extension's own:

C:\Users\walke\.vscode\extensions\anthropic.claude-code-<version>-win32-x64\resources\native-binary\claude.exe

Reproduced on three extension versions: 2.1.259, 2.1.258, and 2.1.121. Since 2.1.121
is ~138 versions older, this does not appear to be a recent regression.

Environment

| | |
|---|---|
| OS | Windows 11 Pro 10.0.26200 |
| VS Code | 1.136.0 |
| Extension | anthropic.claude-code 2.1.259, 2.1.258, 2.1.121 (all affected) |
| CLI | 2.1.259, native install at ~\.local\bin\claude.exe |
| Account | Max 20x, single account, organizationRole: admin |
| Auth | OAuth only — no ANTHROPIC_API_KEY, no apiKeyHelper, no customApiKeyResponses |

Steps to reproduce

  1. Sign in to Claude Code (either surface); ~/.claude/.credentials.json is written.
  2. Open the Claude Code panel in VS Code and interact with it.
  3. Within ~10–20 seconds the credentials file is deleted. The panel shows a sign-in

prompt and any running CLI session reports "Not logged in · Please run /login".

  1. Sign in again — the file is deleted again, usually within seconds.

An idle panel does not appear to trigger it; panel activity (typing, or the panel
spawning its per-request claude.exe) does.

Evidence: audited deletions

Windows file auditing (SACL on ~\.claude, auditpol Object Access → File System)
recorded these. Each line is event 4660 correlated to its 4656/4663 by HandleId:

20:30:08.017   PID 1968    ...anthropic.claude-code-2.1.259-win32-x64\...\claude.exe
20:30:29.633   PID 38240   ...anthropic.claude-code-2.1.259-win32-x64\...\claude.exe
20:41:38.610   PID 1804    ...anthropic.claude-code-2.1.258-win32-x64\...\claude.exe
20:42:01.053   PID 24540   ...anthropic.claude-code-2.1.258-win32-x64\...\claude.exe
20:46:50.157   PID 4480    ...anthropic.claude-code-2.1.121-win32-x64\...\claude.exe

Target file in every case: C:\Users\walke\.claude\.credentials.json

Two properties worth noting:

  • The deleting PIDs are short-lived spawns. None of 1968, 38240, 1804, 24540, or 4480

appear in a process listing captured a fraction of a second later. The panel spawns a
claude.exe, it deletes the file, it exits.

  • A polling watcher that only lists running processes cannot catch this — by the time

it samples, the culprit is gone. This is likely why the failure has been hard to
attribute.

Two distinct deletion paths

Path A — server-side revocation (logged). One occurrence had a clear cause in the
extension log:

19:52:48.253  webview → io_message                    (user submits a message)
19:52:48.314  [API REQUEST] /v1/messages source=sdk
19:52:48.419  [ERROR] API error 401
              {"type":"authentication_error",
               "message":"OAuth access token has been revoked."}
19:52:48.436  Getting authentication status → No authentication found
19:52:48.618  credentials file gone

The revoked token had authenticated a successful call 22 seconds earlier:

19:52:25   panel login completes, credentials written
19:52:26.7 fetchUtilization: GET /api/oauth/usage → 200 after 1 attempt(s)
19:52:48.4 same token → /v1/messages → 401 revoked

Client request IDs from that failure: 4915d1f7-e3b3-4900-9dd8-c5d68d8219cc,
f1a12460-37f4-46b2-8910-43c2daade0b6.

Path B — silent deletion (not logged). Most deletions have no 401, no error, no
logout request, and no user message anywhere in the extension log. Example at 20:12:07:
a panel process started at 20:11:46, and 21 seconds later the file was gone with
grep -c "401|revoked|logout|io_message" returning 0 for that window. Path B is the
common case.

Expected vs actual

Expected: an auth failure in the VS Code panel should, at most, sign out the panel,
and only after a real credential failure. A revoked-token 401 on one request should not
delete the shared credential store used by other processes.

Actual: the panel's bundled binary deletes the shared credentials file — in the common
case with no logged error at all — signing out the CLI and any other running session on
the machine.

Impact

  • The VS Code panel cannot be used; it signs itself out within seconds of each login.
  • Collateral damage to the CLI: unrelated terminal sessions lose auth mid-task, because

both surfaces read ~/.claude/.credentials.json.

  • Users cannot work around it at the login prompt — the deletion is faster than a login.

Things ruled out during investigation

| Hypothesis | Ruled out by |
|---|---|
| Version mismatch panel vs CLI | Both 2.1.259; also reproduced on 2.1.258 and 2.1.121 |
| Recent regression | 2.1.121 (~138 versions older) is affected |
| Stale second-account token | Second config dir moved aside; behavior unchanged |
| A second credential store (Credential Manager / state.vscdb) | No Anthropic entries in either; extension reads claudeAiOauth from .credentials.json |
| CLI/panel race over the file | A deletion occurred with only panel processes running, no CLI |
| Desktop app interference | Desktop app authenticates to its own sandboxed store (AppData\Local\Packages\Claude_pzs8sxrjxfjjc); its login left .credentials.json byte-identical |
| Malformed credential | Token has full scopes (user:profile user:inference user:mcp_servers user:sessions:claude_code user:file_upload); a healthy in-place refresh was observed at 20:42:34 |
| Env-var / API-key precedence | No ANTHROPIC_API_KEY, no apiKeyHelper, no customApiKeyResponses, no machine/user env overrides |

Workaround

Disable the VS Code extension and use the CLI. Credentials persist indefinitely when no
panel process is running.

Suggested fix

Narrow the conditions under which the credential store is deleted:

  1. Don't delete shared credentials on a 401 from a single API request. Attempt a refresh

first; only clear on a definitive refresh-token failure (e.g. invalid_grant).

  1. Log every deletion of .credentials.json with the reason, at INFO. Path B currently

leaves no trace, which makes this effectively undiagnosable without OS-level auditing.

  1. Consider whether a per-surface credential invalidation is possible, so a panel-side auth

failure doesn't sign out unrelated CLI sessions sharing the file.

Reproduction tooling

If useful, the audit setup that produced the attribution above:

# elevated, once
auditpol /set /subcategory:"File System" /success:enable /failure:enable
$acl = Get-Acl "$env:USERPROFILE\.claude" -Audit
$acl.AddAuditRule((New-Object System.Security.AccessControl.FileSystemAuditRule(
  "Everyone","Delete,DeleteSubdirectoriesAndFiles","ObjectInherit","NoPropagateInherit","Success,Failure")))
Set-Acl "$env:USERPROFILE\.claude" $acl

# then correlate 4660 (delete) back to 4656/4663 (open/access) by HandleId
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4656,4660,4663;StartTime=(Get-Date).AddMinutes(-15)}

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.259

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

_No response_

View original on GitHub ↗