auto mode: environment setup pins an absolute trusted-repo path into user-global settings, so every other project inherits the wrong trust boundary

### Summary

`autoMode.environment` is written to **user-global** `~/.claude/settings.json` by the auto-mode environment setup. One of its entries is `**Trusted repo**`, and it is stored as an **absolute path to whichever project happened to run the setup**:

```json
"autoMode": {
"environment": [
"...",
"**Trusted repo**: The git repository the agent started in (C:\\Users\\me\\ProjectA) — no remotes configured, so scope is limited to this local working directory",
"..."
]
}
```

Because the file is user-global, that path then applies to **every other project on the machine**. Starting Claude Code in `D:\ProjectB` leaves the classifier believing the trusted repo is still `ProjectA`, so ordinary work inside `ProjectB` — reading its own files, writing its own config — is classified as reaching outside the trust boundary.

### Impact

The failure is silent and the symptom is far from the cause. What the user sees is a flood of permission prompts and classifier denials in a project that is plainly trusted; nothing names the stale path, and `/config`, the permission allowlist, and `additionalDirectories` all look correct because none of them is the thing that is wrong.

In our case this cost a full day of troubleshooting and ended in an unnecessary rollback to an older release, on the theory that a recent version had regressed permissions. It had not — a months-old entry from an unrelated project was still in effect.

The entry is also stale in a second way: it records facts *about* that repo ("no remotes configured", visibility, protected branches) which are simply wrong for the project actually open.

### Reproduce

1. Run the auto-mode environment setup in project A (`C:\Users\me\ProjectA`). Note the absolute path written into `~/.claude/settings.json` under `autoMode.environment`.
2. Start Claude Code in an unrelated project B (`D:\ProjectB`), with its own git repo and its own `.claude/settings.local.json`.
3. Ask it to edit a file inside project B, or inside the user's own `~/.claude/`.
4. The classifier reasons from project A's trust boundary. Expected-routine actions are denied or escalated, with no indication that a stale path is responsible.

### Expected

Any one of these would have prevented the day:

1. **Resolve the trusted repo per session** from the actual working directory, rather than freezing an absolute path at setup time. The entry already says "the git repository the agent started in" — it should mean that literally, not a snapshot of where it was first run.
2. **Write the environment block project-scoped** — into that project's `.claude/settings.local.json` — and keep only genuinely machine-wide facts (org, cloud provider, network posture) in the user-global file. The project-specific half and the org-wide half currently live in one array with one scope.
3. **Warn on mismatch.** If `autoMode.environment` names a trusted repo that is not the current working directory, say so once at startup. A single line — "auto mode trust boundary names `C:\Users\me\ProjectA`, but you are in `D:\ProjectB`" — turns a day into a minute.
4. **Surface it in `/config` or `/status`**, so the effective trust boundary is inspectable without reading raw JSON.

### Workaround

> **Correction (2026-09-10):** the project-scoped half of this workaround does **not** work and never did - `autoMode` is read only from user, `--settings` and managed settings, and a block in a repo's `.claude/settings.json` or `.claude/settings.local.json` is parsed and then ignored as repo-controllable. Details, and the consequence for Expected item 2, in [this comment](https://github.com/anthropics/claude-code/issues/93405#issuecomment-5628954503). Only the de-pinning half of the paragraph below holds.

Setting `autoMode.environment` in the project's own `.claude/settings.local.json` appears to override the user-global copy, since project settings load after user settings and `autoMode` carries none of the "only honored from user/managed settings" restrictions that other keys document. Every project then needs its own block, and the user-global entry has to be manually de-pinned so it stops naming a specific repo — neither is discoverable.

### Environment

- Claude Code 2.1.226 and 2.1.267 (behaviour identical; the rollback between them was chasing the wrong cause)
- Windows 11, native installer
- Auto mode enabled

Reproduce with two local git repos and inspect ~/.claude/settings.json for autoMode.environment; also check how .claude/settings.local.json is treated. Search for autoMode.environment setup, settings loading, and the /config or /status display paths. Done means ProjectB no longer silently inherits ProjectA's trusted-repo path, or the mismatch is clearly warned or inspectable.

Written by the indexing model from the issue text.