[BUG] Desktop app: sessions read a stale, isolated filesystem view that never re-syncs

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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?

# Desktop app serves a permanently stale, isolated copy of a directory; VS Code extension sees the real disk

## Summary

On the same Windows machine, sessions running in the **Claude Code desktop app** read and write
an isolated copy of `%APPDATA%\netlify\Config\`. The copy holds a state from the previous day,
never re-syncs with the real filesystem, and writes made into it are invisible from outside.
A session running in the **VS Code extension** on the same machine, same user, same paths sees
the real directory and live updates.

Nothing is lost or corrupted — the real files are untouched — but the affected sessions report
filesystem state that does not exist, confidently and with no error of any kind. The only way we
found to detect it was to compare against something outside the app.

## Environment

- Claude Code `2.1.252`
- Windows 10 Pro 10.0.19045, user `sergedem`, single local profile
- Affected: Claude Code desktop app (all sessions)
- Not affected: Claude Code VS Code extension; the user's own MINGW64 terminal
- Node `v24.19.0`, `netlify-cli/27.4.2` (installed at `%APPDATA%\npm`)
- Dates below are 2026-08-31 and 2026-09-01

## Steps to reproduce

Exact steps that produced it here. I cannot say which of them are essential.

1. In a desktop app session, install a CLI that keeps a config directory under `%APPDATA%`
(here: `npm install -g netlify-cli`, which uses `%APPDATA%\netlify\Config\`).
2. From that same desktop session, run a command that makes the CLI write to that directory
(`netlify status` — its config store rewrites the file on every invocation).
3. Outside the app, change that directory: log in to the CLI so it stores credentials, and
reinstall the CLI so a cached file in the same directory is regenerated.
4. From any desktop app session, list the directory. It shows the state from step 2, not the
real one — and keeps showing it indefinitely.

## Expected vs actual

**Expected:** a session reads the real filesystem, or fails loudly if it may not.

**Actual:** the session reads a copy frozen at an earlier point, writes into that copy, and
reports both as if they were the real filesystem. No error, no warning, no indication that the
view is not authoritative.

## Evidence

Same path (`C:\Users\sergedem\AppData\Roaming\netlify\Config\`), same binary, same `APPDATA` in
child processes, verified in all sessions.

| File | Real disk (VS Code session + user's terminal) | Desktop app sessions |
|---|---|---|
| `autocompletion.json` | 39246 bytes, 2026-09-01 13:00:57 | 27715 bytes, **2026-08-31** 16:54:04 |
| `config.json` | 481 bytes (contains the login) | 81 bytes (CLI defaults only) |
| marker file created by a desktop session | not present | present, readable |

**Ground truth.** The user ran `stat -c '%s %y' "$APPDATA/netlify/Config/autocompletion.json"`
in their own MINGW64 terminal, outside all sessions: `39246 2026-09-01 13:00:57`. This matches
the VS Code session, not the desktop sessions.

**Writes do not reach disk.** A desktop session created `zz-marker-e1.txt` in that directory
twice. Both times it was visible to desktop sessions and absent from the real directory as seen
by the VS Code session and by the user. The real `config.json` kept its 481 bytes and the user's
login kept working throughout.

**Reads do not fall through either.** `autocompletion.json` was never written by any session,
yet desktop sessions see a version one day old. So this is not copy-on-write with fallthrough
for unmodified files.

**The copy is shared, not per-session.** Two desktop sessions see each other's writes: running
`netlify status` in one moved the `config.json` mtime observed by the other.

**Visible symptom for the user.** `netlify status` reports `Not logged in` in every desktop
session while the user is logged in and their terminal shows the account. Following that at face
value leads to advising the user to re-authenticate, or to issue a personal access token, for a
problem that does not exist.

## Ruled out

Each of these was tested, not assumed.

- **Not a stale snapshot of `%APPDATA%`.** `npm ls -g` from a desktop session shows the
`netlify-cli` version installed today in the neighbouring `%APPDATA%\npm`. The divergence is
scoped to one directory while its sibling is live.
- **Not per-session.** A new session created in the running app shows the same copy.
- **Not tied to the app process.** A new session created after fully quitting and restarting the
desktop app shows the same copy.
- **Not tied to the working directory.** A session opened on an unrelated project shows the same
copy.
- **Not the tool sandbox toggle.** Running the same check with the sandbox disabled changes
nothing.
- **Not a different path or profile.** `FullName` and `process.env.APPDATA` were compared across
sessions and match character for character. No alternative config locations exist on the
machine.
- **Not the CLI.** Same binary, same version, resolved from the same path in every session.

## Unexplained

In the copy, `config.json` is 81 bytes — the defaults a fresh CLI writes when it finds no config.
But the real file already contained a stored user record (dating back to 2022) before the desktop
session ever ran that CLI. A plain directory copy would have carried that record over. So
whatever produced the copy did not simply clone what was on disk at that moment.

Also worth noting: direct reads of `config.json` are blocked by the permission classifier in both
the affected and unaffected sessions, so that block is not what distinguishes them.

## Impact

The data risk is low — real files are not modified. The reasoning risk is high. A session in this
state describes the machine incorrectly and has no way to notice: every internal check it runs
agrees with itself. In this case three separate wrong diagnoses were built and discarded before
an outside measurement settled it, across several hours and three sessions. A single-session user
with no second surface to compare against would have no way to detect it at all.

If the isolation is intentional, the session should be told, so it can qualify what it reports
instead of asserting stale state as fact.

## Cheap detection, if useful to others

From the suspect session, write a marker into the directory and have anything outside the app
look for it:

```bash
printf 'marker\n' > "$APPDATA/some/config/dir/zz-marker.txt"
```

Not visible from a terminal — the session's view of that directory is isolated. Comparing sizes
of an ordinary non-secret file in the same directory works as a second signal.

### What Should Happen?

A session should read the real filesystem. If a directory is deliberately isolated from
sessions — sandboxing, credential protection, or anything else — the session should be told:
an error, a warning, or a flag in the tool result. Silent substitution is the problem, not
the isolation itself.

Concretely, for the case in this report: `ls` and `stat` on %APPDATA%\netlify\Config\ from a
desktop app session should return what the user's own terminal returns (autocompletion.json
= 39246 bytes, 2026-09-01 13:00:57), and a file the session writes into that directory should
either appear on the real disk or fail visibly. Today neither happens — the session sees a
copy from the previous day, its writes go nowhere, and nothing indicates the view is not
authoritative. Every internal check the session runs agrees with itself, so it cannot detect
the condition on its own.

If the isolation is intentional and cannot be lifted, the minimum acceptable behaviour is
that it be discoverable from inside the session, so the session can qualify what it reports
instead of asserting stale state as fact.

### Error Messages/Logs

```shell

```

### Steps to Reproduce

Observed with the Netlify CLI, but nothing here looks specific to it — it is simply a program
that keeps a config directory under %APPDATA% and writes to it on every invocation.

1. In a Claude Code desktop app session, install a CLI that stores its config under %APPDATA%:
npm install -g netlify-cli (uses %APPDATA%\netlify\Config\)

2. From that same desktop session, run a command that makes the CLI write into that directory:
netlify status
(its config store rewrites the file on every invocation, even read-only-looking commands)

3. Outside the app, change that directory. Here two things changed it:
- the user ran `netlify login` in their own terminal, so real credentials were stored;
- the CLI was reinstalled, so a cached file in the same directory (autocompletion.json)
was regenerated by the new version.

4. From any desktop app session — the same one, a new one, one opened after fully restarting
the app, or one opened on an unrelated project — list that directory:
ls -la "$APPDATA/netlify/Config/"

It shows the state as of step 2, indefinitely.

5. Compare against anything outside the desktop app. Either surface works:
- the user's own terminal: stat -c '%s %y' "$APPDATA/netlify/Config/autocompletion.json"
- a Claude Code session in the VS Code extension, same machine, same user

VERIFICATION — the divergence is visible in both directions:

Reads: desktop sessions report autocompletion.json as 27715 bytes / 2026-08-31 16:54,
while the terminal and the VS Code session report 39246 bytes / 2026-09-01 13:00.
No session ever wrote this file; it simply never refreshed.

Writes: create a marker from a desktop session —
printf 'marker\n' > "$APPDATA/netlify/Config/zz-marker.txt"
It is visible to desktop sessions and absent from the real directory as seen from
the terminal and the VS Code session.

LIKELY MINIMAL REPRODUCTION (not verified here): any program run from a desktop session that
writes into a directory under %APPDATA% may pin that directory to a copy for all desktop
sessions. We only ever observed it for %APPDATA%\netlify\Config, and the neighbouring
%APPDATA%\npm stayed live throughout, so the boundary is not understood.

### Claude Model

None

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

_No response_

### Claude Code Version

Version 1.40609.0 (f65e38) for Windows and 2.1.252 CLI

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

Terminal.app (macOS)

### Additional Information

_No response_

Start by reproducing the divergence with netlify-cli and %APPDATA%\netlify\Config\, comparing desktop sessions with a terminal or VS Code session. Check whether the desktop app's filesystem isolation or sandbox boundary is responsible, using the marker-file and file-size comparisons described in the report. Done means reads reflect the real filesystem, writes reach disk or fail visibly, and intentional isolation is discoverable inside the session.

Vom Indexierungsmodell aus dem Issue-Text verfasst.