fix(agent-isolation): read the main checkout's settings in a linked worktree (#1229) * fix(agent-isolation): read the main checkout's settings in a linked worktree The status line claimed a sandbox a worktree session did not have. It walked `/.claude/` and then user scope, but Claude Code scopes a linked git worktree's project to the *main* checkout — that is where `/sandbox` persists the toggle and where `.claude/.cc-writes` lands. The worktree's own `settings.local.json` holds only the per-worktree filesystem allowlist `sandbox-add-project-root.sh` writes, with no `enabled` key at all, so the walk fell through to `~/.claude/settings.json` and painted a green `[sandbox]` on a session the operator had deliberately switched out of the sandbox. That is the one failure mode this status line exists to prevent. Resolve the working-tree root and the main checkout by comparing `git rev-parse --git-dir` with `--git-common-dir` — they differ in a linked worktree and nowhere else — and insert both between `` and user scope in the settings walk. The working-tree root also closes a latent miss: a `` below the tree root has no `/.claude/` to read, so project scope was skipped there too. The same resolution replaces the hardcoded `*/.claude/worktrees/*` substring match in the folder segment. `/` rendering now covers every layout instead of the single one it enumerated: worktrunk's sibling `./` directories (the repeated repo prefix is stripped, so `cpython.gh-156021` reads `cpython/gh-156021`), Claude Code's own `.claude/worktrees/`, and a plain `git worktree add` anywhere on disk. Because the test is a property of git rather than of a naming scheme, a worktree manager does not have to be enumerated here to be supported. Covered by a new test module: settings precedence across main, worktree and user scope, subdirectories on both sides, and folder rendering per layout. Generated-by: Claude Code (Opus 5) * test(agent-isolation): parametrize the status-line cases, drop the classes Each test was a class method repeating the same three steps — build a layout under tmp_path, run the script, assert on one segment of the line. Collapse them into a frozen `Case` dataclass, one `_build`, and a single `@pytest.mark.parametrize` run, and every case now asserts both the sandbox tag and the folder segment rather than whichever one it was written for. 13 cases, no classes; a new layout is one entry. Also state in the script header and the test docstring that this helper is Claude-Code-only, unlike the harness-agnostic scripts beside it: it is wired through Claude Code's `statusLine`, fed Claude Code's payload, and reads Claude Code's settings schema. That is why `.claude/` is the only settings directory under test. Generated-by: Claude Code (Opus 5) * test(agent-isolation): revert the status-line parametrization Restore the class-grouped tests from 8aa6fd9. The parametrized form collapsed the layouts into one `Case` table, which reads well as a matrix but loses the grouping that says *why* a case exists — the settings walk and the folder rendering are separate concerns that happen to share a fixture, not one table with two columns. Keeps the Claude-Code-only note added alongside it: the docstring still says why `.claude/` is the only settings directory under test. Generated-by: Claude Code (Opus 5) * docs(agent-isolation): say that the status line is Claude Code only `tools/agent-isolation/README.md` tagged the whole directory **Harness: agnostic**, which is true of every script in it except this one: `sandbox-status-line.sh` is wired through Claude Code's `statusLine` setting, is fed Claude Code's statusLine payload on stdin, and reads Claude Code's `sandbox.enabled` schema. Nothing said so, so a reader comparing harnesses had no way to tell the exception from an omission. Note it in the directory's harness tag, in its Files row, and in the status-line section of the secure-agent-setup document, each pointing at `docs/adapters/add-a-harness.md` for a harness that grows one. The setup document also names the harness-agnostic half of sandbox visibility — the bypass-warning hook, which fires on the tool call rather than in the footer. Generated-by: Claude Code (Opus 5) * fix(agent-isolation): keep the Harness tag machine-readable a337b03 wrote `**Harness:** agnostic, except sandbox-status-line.sh — Claude Code only`, and the vendor-neutrality-score hook parses that field as a comma-separated list of harness names: error: tools/agent-isolation: unknown harness(es) ['agnostic', 'except'] The field is data, not prose. Put `agnostic` back in it and state the one exception in a sentence below, where a reader gets the same information and the parser is not asked to read English. Generated-by: Claude Code (Opus 5) * fix(agent-isolation): read the main checkout first, not a bare repo's parent Two corrections to the settings walk this branch introduces. The walk put and the working-tree root ahead of the main checkout, so an `enabled` written by hand into a linked worktree's own settings won over the main checkout. Claude Code does not read that file — it scopes a linked worktree's project to the main checkout — so the more specific file is precisely the one that cannot describe the session. A worktree saying `true` over a main checkout saying `false` rendered a green [sandbox] on a session that had none, which is the failure this status line exists to prevent. The main checkout now leads the walk, and the test that asserted the old order asserts the new one. `main_root` was derived as the parent of `--git-common-dir`, which assumes the common dir is `

/.git`. For `git clone --bare` plus `git worktree add` it is `.git`, so the parent is whatever directory happens to contain the bare repo: its `.claude/settings.json` was read as project scope, and the folder segment rendered that directory's name rather than the repository's. The derivation is now guarded on the `.git` suffix — a bare common dir yields no project scope and the walk falls through to user scope, while the folder segment still names the repository, taken from the bare directory (`proj.git` -> `proj/feature-x`). Also guards the comparison on a non-empty `--git-dir`, so a `--git-dir` that fails to resolve no longer reads as "linked worktree". Generated-by: Claude Opus 5 --------- Co-authored-by: Jarek Potiuk

Sunbelt Computer Software

PL/B Language Development and Support

Uh oh!