[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ACZP9DDV8ZCE5BSSBBGC5T":3,"skill-same:01M6ACZP9DDV8ZCE5BSSBBGC5T":141},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":63,"repositoryHtmlUrl":64,"repositoryHomepageUrl":65,"ownerHtmlUrl":66,"ownerBlogUrl":67,"ownerDescription":6,"updatedAt":68,"install":69,"resources":82},"01M6ACZP9DDV8ZCE5BSSBBGC5T","isolated-setup-doctor",null,"Probe the secure-agent setup for restrictions that block legitimate work — SSH agent reachability, port binding, containers, the scratch directory, the signing key, `gh` outside the sandbox, `prek` and `uv` inside it, the global git hook dir. Names the troubleshooting entry and settings fix for each. Read-only.","apache\u002Fmagpie","apache","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F47359?v=4","01M6AC83E6K4FDKK7HZ8WNMQKE","The Apache Software Foundation","01M6ACRKRED1THWRMNQ1E2RYE7",142,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"isolated setup doctor","setup","doctor","unreachable","when","errors","socket","agent setup","hook","permission","read","why","work","port","reports","upgrade","uv","only","fix","Meta","git","secure","directory","harness","reassess","2026-11-10 10:12:30",false,"---\n# SPDX-License-Identifier: Apache-2.0\n# https:\u002F\u002Fwww.apache.org\u002Flicenses\u002FLICENSE-2.0\nname: isolated-setup-doctor\nfamily: setup\nmode: Meta\ndescription: >-\n  Probe the secure-agent setup for restrictions that block legitimate\n  work — SSH agent reachability, port binding, containers, the scratch\n  directory, the signing key, `gh` outside the sandbox, `prek` and\n  `uv` inside it, the global git hook dir. Names the\n  troubleshooting entry and settings fix for each. Read-only.\nwhen_to_use: >-\n  When the user says \"doctor my sandbox\", \"why is the sandbox blocking\n  X\", or reports a failure that smells sandbox-shaped — agent\n  unreachable, socket errors, permission errors on a port. Also worth\n  running after an agent harness upgrade, since the sandbox profile\n  moves.\ncapability:\n  - capability:platform\n  - capability:reassess\nsurface_hash: sha256:f8a5db3da24024cb\nlicense: Apache-2.0\nmeasured_tokens: 7041\n---\n\n\u003C!-- Placeholder convention (see AGENTS.md#placeholder-convention-used-in-skill-files):\n     \u003Cproject-config> → per file: the personal layer, else `.apache-magpie-overrides\u002F` -->\n\n# setup-isolated-setup-doctor\n\n## Runtime routing (run before the Claude-specific probes)\n\nUse the operator's explicitly requested runtime when supplied; otherwise use the active session's runtime.\nAn installed executable or configuration directory alone does not select a runtime.\nFor the routing below, treat that selection as the active harness.\n\nWhen the active harness is Codex, first require the static verification in [docs\u002Fadapters\u002Fcodex.md](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fadapters\u002Fcodex.md#verify), then run the shared live environment probes inside the active Codex sandbox.\nAttribute failures separately to native sandbox\u002Fnetwork denial, approval policy, or the POSIX agent-iso layer.\nDo not prescribe a `.claude` settings change for a Codex failure.\nThen stop before the Claude-specific branch below.\n\nWhen the selected runtime is Antigravity, follow\n[docs\u002Fadapters\u002Fantigravity.md](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fadapters\u002Fantigravity.md#doctor): verify the user-scope profile first, then diagnose the actual tool result in the active Antigravity session.\nDistinguish sandbox limits, permission-rule denials, guard-hook failures, and wrapper or authentication problems.\nDo not require Claude configuration or prescribe Claude settings changes; then stop before the Claude-specific probes below.\n\nWhen the selected runtime is Goose, follow\n[docs\u002Fadapters\u002Fgoose.md](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fadapters\u002Fgoose.md#doctor): verify the plugin, its sandbox runtime and the launcher first, then diagnose the actual tool result in the active Goose session.\nDistinguish sandbox limits or a missing sandbox runtime, hook denials (deny rules or the guard), a hook that failed closed, approve-mode declines, and wrapper or provider-key problems.\nDo not require Claude configuration or prescribe Claude settings changes; then stop before the Claude-specific probes below.\n\nWhen the selected runtime is Pi, follow\n[docs\u002Fadapters\u002Fpi.md](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fadapters\u002Fpi.md#doctor): verify the package install first, then diagnose the actual tool result in the active Pi session.\nDistinguish sandbox limits or a sandbox that could not start, permission-rule denials, guard denials, and wrapper or authentication problems.\nDo not require Claude configuration or prescribe Claude settings changes; then stop before the Claude-specific probes below.\n\nWhen the selected runtime is Copilot CLI, follow [docs\u002Fadapters\u002Fcopilot.md](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fadapters\u002Fcopilot.md#doctor): verify the hook first, then diagnose the actual tool result in the live session.\n\nWhen the harness is Claude Code, continue below.\nIf the harness cannot be determined, ask once.\n\nThis is the diagnostic layer over the secure agent setup.\n[`verify`](..\u002Fisolated-setup-verify\u002FSKILL.md) checks statically that the setup is *installed* right, catching drift and missing pieces.\nThis skill checks whether common workflows are *functionally blocked* by the sandbox as configured, catching over-restrictive allowlists.\n([`install`](..\u002Fisolated-setup-install\u002FSKILL.md) puts the setup in place; [`update`](..\u002Fisolated-setup-update\u002FSKILL.md) reports framework drift.)\n\nRun `verify` first when the install itself is in doubt: fresh machine, recent upgrade, sandbox-state surprise.\nRun `doctor` when the install is known good and a workflow fails in a sandbox-shaped way: agent unreachable, socket error, port permission error.\n\nEvery probe maps to a numbered entry in [`docs\u002Fsetup\u002Fsandbox-troubleshooting.md`](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md).\nThe doctor identifies *which* entry applies now; it does not re-explain the remediation.\nIf a fail shows a failure mode not catalogued there, propose appending a new entry per the catalog's *Adding a new entry* section.\n\n## Golden rules\n\n- **Read-only.** Each probe is a small, deterministic, side-effect-free check.\n  The skill **never** edits a settings file, **never** runs a command with `dangerouslyDisableSandbox`, and **never** installs anything.\n  If a check fails, surface it and point at the catalog entry; do not auto-fix.\n- **Run every probe, even on early failure.** Do not stop at the first ✗.\n  A user may have one of eight independent restrictions or all eight, and finding them one re-run at a time is annoying.\n- **Distinguish ✗ (failing) from ⊘ (not applicable).** ✗ means the probe ran and the sandbox blocked it.\n  ⊘ means the probe was skipped because a prerequisite is absent (e.g. no `docker` \u002F `podman` on `PATH` → docker probe ⊘, not ✗).\n- **Surface evidence.** Each report line names the probe command, the exit code, and the relevant stderr snippet.\n  \"Looks blocked\" is not useful; \"ssh-add -l → rc=2 → `Could not open a connection to your authentication agent`\" is.\n- **Sandbox placeholders are not files.** Inside the Claude Code sandbox a denied path that does not exist on the host can appear as a `\u002Fdev\u002Fnull` bind mount: `stat -c '%F %t,%T' \u003Cpath>` prints `character special file 1,3`.\n  `git status` lists such placeholders as untracked (`.bash_profile`, `.claude\u002Fsettings.json`, `.mcp.json`), and reading one returns nothing.\n  Take the host state from git (`git ls-files \u003Cpath>`, `git log -- \u003Cpath>`) or from a read the user runs outside the sandbox, and never delete the placeholder.\n- **Map each ✗ to a catalog entry.** The fail report links directly to the matching section of [`docs\u002Fsetup\u002Fsandbox-troubleshooting.md`](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md).\n  Do not paraphrase the remediation; the catalog is the single source of truth.\n\n## The probes\n\nThe probes cover the catalog's failure modes that a sandboxed command can detect on its own; the signing entries that need a live touch or a terminal are verified by `setup-isolated-setup-verify` check 10 instead.\nNew probes are added when new entries land in the catalog, so the two stay in lock-step.\n\n### Probe 1 — SSH agent \u002F Yubikey reachable\n\nTests whether `ssh-agent` is reachable from inside the sandbox.\nTwo failure modes:\n`SSH_AUTH_SOCK` passes through `claude-iso`'s env whitelist but the socket file is not in `sandbox.filesystem.allowRead`, so the agent's `ssh` \u002F `git push` subprocesses cannot even `stat(2)` it;\nor, on macOS, the file is readable but its path is missing from `sandbox.network.allowUnixSockets`, so `connect(2)` is denied and the agent looks unreachable while the socket is plainly there.\nA signed commit hits the second as `No private key found for public key`.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-1-ssh-agent.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ N identities listed` | Pass | `ssh-add -l` returned the key list. |\n| `✓ agent reachable, no identities` | Pass | `ssh-add -l` returned rc=1 (the documented \"no keys\" exit). |\n| `✗ socket not stat-able` | Fail | Sandbox blocks `stat(2)` on the socket file. |\n| `✗ agent unreachable` | Fail | Sandbox blocks `connect(2)` to the socket. |\n| `⊘ SSH_AUTH_SOCK not set` | Skip | Either the user does not run `ssh-agent`, or `claude-iso`'s env whitelist dropped it (separate bug — verify). |\n\n**On ✗ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — SSH agent \u002F Yubikey appears unreachable from inside the sandbox](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#ssh-agent--yubikey-appears-unreachable-from-inside-the-sandbox).\n\n### Probe 2 — Localhost port bind\n\nTests whether a process inside the sandbox can bind to a loopback port AND then talk to itself over loopback.\nThe catalog documents the second half failing (egress proxy blocks `127.0.0.1`).\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-2-localhost-bind.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ bound + loopback GET → HTTP 200` | Pass | Both bind and loopback HTTP work. |\n| `✗ bind: [Errno 1] Operation not permitted` | Fail | The sandbox refuses listening sockets outright; `sandbox.network.allowLocalBinding` is unset. Fails before any egress rule is consulted, so `allowedDomains` changes do not help. |\n| `✗ bind: ...` (other errno) | Fail | The sandbox blocks `bind(2)` on `127.0.0.1` for another reason. Rare; report the literal error. |\n| `✗ bind ok, loopback GET: ...` | Fail | Bind works but the sandbox egress proxy refuses `127.0.0.1` as a destination. Common shape. |\n\n**On ✗ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — Test cannot bind to a localhost port](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#test-cannot-bind-to-a-localhost-port).\n\n### Probe 3 — Podman \u002F Docker through the container gateway\n\nTests whether the runtime CLI can talk to the [container gateway](..\u002F..\u002F..\u002F..\u002Ftools\u002Fcontainer-gateway\u002FREADME.md), not the real daemon socket; the sandbox never gets a route to the daemon itself.\nRun it for each of `podman` \u002F `docker` on `PATH`; ⊘ each one not installed (an absent prerequisite, not a sandbox failure).\nThe remaining checks narrow down which of the three wiring pieces (env var, running gateway, allowed socket) is missing, in the order a fresh install would hit them.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-3-container-gateway.sh\n```\n\n`status_json` comes from the gateway's own read-only `status` subcommand.\nThe doctor may call it from inside the sandbox, since it neither binds a socket nor touches the daemon.\n`gw_src` picks the adopter's pinned snapshot (`.apache-magpie\u002Ftools\u002Fcontainer-gateway\u002Fsrc`) when present, else the framework repo's own tree (`tools\u002Fcontainer-gateway\u002Fsrc`), else the operator install the `SessionStart` hook runs (`~\u002F.claude\u002Fscripts\u002Fcontainer-gateway\u002Fsrc`), so the same probe runs in an adopted checkout, in this framework's own worktree and on a marketplace install.\nThe operator install is readable inside the sandbox only when the project's gateway wiring grants `~\u002F.claude\u002Fscripts\u002Fcontainer-gateway\u002F` in `sandbox.filesystem.allowRead`; without it the directory is visible but its files are not, so the probe checks a file before calling `status`.\nOnly `status` can vouch that the socket is the gateway's — a raw daemon socket answers `\u003Crt> info` just as well — so with no status (no gateway source, or one the `PATH` `python3` cannot import) the probe fails rather than trusting the socket.\nA `status` that exits 2 without a report has refused the run directory.\nThe `gw_state` check runs **before** the raw socket-file test.\nA backend that `status` does not list under `serving` never gets a socket file, so testing `-S \"$sock\"` first would misreport \"gateway not running\" for the \"running, but this backend's machine\u002Fdaemon is down\" case.\nThe `-S` test is a defensive fallback for an already-serving backend whose socket vanished mid-probe, not the primary check.\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ \u003Crt> reaches the container gateway at \u003Csock>` | Pass | CLI → gateway → daemon all answer. |\n| `✗ … unset — gateway not wired into settings` | Fail | The reference `env` block is missing from project settings. |\n| `✗ gateway socket missing` | Fail | The `SessionStart` hook did not start the gateway, or it exited and no `PreToolUse` `ensure` hook started it again before the probe's container command (check 12a of `setup-isolated-setup-verify` flags a missing one); check `container-gateway.log` in the gateway's run directory — `\u003Cproject>\u002F.apache-magpie-local\u002Frun\u002F` when adopted, else `\u003Cgit-common-dir>\u002Fapache-magpie\u002Frun\u002F\u003Cworktree-id>\u002F`. |\n| `✗ gateway status refused the run directory` | Fail | `status` exited 2 without a report: a run-directory component is a symlink or has the wrong owner, type or mode. Inspect the run directory from outside the sandbox; do not point the CLI around it. |\n| `✗ gateway status unavailable` | Fail | The probe could not get a report from `status`: no gateway source was found (install the operator copy, install Step L.1), the operator copy is not readable inside the sandbox (`gateway source at … is not readable`: the `allowRead` grant in the project's gateway wiring is missing), or `status` exited without one (`rc=N`; typically a `python3` on `PATH` too old to import the gateway). The socket may still work, but nothing confirms it is the gateway's. |\n| `✗ gateway running without a \u003Crt> backend` | Fail | `status` reports the gateway up but `serving` does not list this CLI's backend — the Podman machine or Docker daemon behind it is not running. Start it from outside the sandbox, then restart the gateway. |\n| `✗ connect … denied` | Fail | The gateway socket is not in `sandbox.network.allowUnixSockets`. |\n| `✗ gateway up, backend down` | Fail | Podman machine \u002F Docker not running on the host; start it from your own terminal. |\n| `✗ no response in 15s — \u003Crt> info hung` | Fail | `_probe_timeout` killed a stalled `\u003Crt> info` call; the backend daemon behind the gateway is likely wedged — restart it from outside the sandbox. |\n| `⊘ \u003Crt> not on PATH` | Skip | Runtime not installed; not a sandbox restriction. |\n\nAn empty `podman machine list` from inside the sandbox is a read denial on the machine's directory, not proof that no machine exists.\nDecide the machine's real state from outside the sandbox, per the catalog entry below.\n\n**On ✗ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — Docker \u002F Podman command fails with a socket error](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#docker--podman-command-fails-with-a-socket-error).\n\n### Probe 4 — Per-project scratch directory (`TMPDIR`)\n\nTests whether the session has a **writable** scratch directory.\nThe sandbox mounts the host `\u002Ftmp` read-only and makes only specific subpaths writable, so a session whose `TMPDIR` falls back to `\u002Ftmp` has no scratch area at all.\n\n`TMPDIR` landing on the shared session root rather than a per-project directory is **not** a finding.\nClaude Code sets `TMPDIR` itself when it builds the sandbox, and that wins over `env.TMPDIR` from any settings file, so the shared root is expected and no configuration changes it.\nEach session still gets a per-project, per-session scratchpad beneath it.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-4-scratch-dir.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ per-project + writable` | Pass | `TMPDIR` resolves under this project's path slug and accepts writes. |\n| `✓ writable; shared session root` | Pass | The expected value on current Claude Code. Every project on the machine shares this directory, so write through the per-session scratchpad beneath it, or use unique filenames — but there is nothing to fix. |\n| `✗ TMPDIR not set` | Fail | Tooling falls back to `\u002Ftmp`, which is read-only inside the sandbox. |\n| `✗ directory missing` | Fail | `TMPDIR` names a path nothing has created yet. |\n| `✗ not writable inside sandbox` | Fail | `TMPDIR` points outside `sandbox.filesystem.allowWrite`. |\n\n**On ✗ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — Temp files fail with \"Read-only file system\" under `\u002Ftmp`](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#temp-files-fail-with-read-only-file-system-under-tmp).\n\nDo **not** propose `env.TMPDIR` in a settings file as the fix.\nClaude Code overrides it when it builds the sandbox, so the setting is accepted and silently has no effect.\nThe giveaway is a directory that exists, is named exactly as configured, and stays empty.\nThe catalog entry above covers what is actually actionable.\n\n### Probe 5 — Signing key readable (`gpg.format=ssh`)\n\nTests whether the public key git hands to `ssh-keygen -Y sign` can be opened from inside the sandbox.\nFailure mode: the framework denies `~\u002F.ssh\u002F` wholesale, so with `gpg.format=ssh` every signed commit fails before the hardware key asks for a touch.\nThe touch overlay, which waits for `ssh-keygen` to block, never sees it block.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-5-signing-key.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ readable inside sandbox` | Pass | `ssh-keygen` will be able to open the public key. |\n| `✓ literal key` | Pass | `user.signingkey` holds the key text itself; no file is involved. |\n| `✗ not readable inside sandbox` | Fail | The sandbox's `~\u002F.ssh\u002F` read deny covers the public key; add that one file to `allowRead`. |\n| `⊘ gpg.format is not ssh` | Skip | Signing goes through gpg (or is off); the agent-socket rules behind Probe 1 are what matter. |\n| `⊘ user.signingkey unset` | Skip | Misconfigured signing, not a sandbox problem — mention it, do not fail the probe. |\n| `signing-program → ✓` | Pass | git's signing program (the touch overlay's `gpg-touch-wrap-*` wrapper, or whatever `gpg.ssh.program` \u002F `gpg.program` names) can be started from inside the sandbox. Nothing printed when neither key is set: git uses its default `ssh-keygen` \u002F `gpg` from `PATH`. |\n| `signing-program → ✗` | Fail | The program git is configured to sign with is read-denied inside the sandbox — for the overlay wrapper, `~\u002F.claude\u002Fscripts\u002F` is. Every sandboxed signed commit fails at once with `cannot exec`; add the wrapper's two files to `allowRead`. |\n\n**On ✗ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — Signed commit fails before any touch when git signs with ssh](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#signed-commit-fails-before-any-touch-when-git-signs-with-ssh)\nfor the key, and\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — Signed commit fails with \"cannot exec\" of the touch-overlay wrapper](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#signed-commit-fails-with-cannot-exec-of-the-touch-overlay-wrapper)\nfor the program.\n\n### Probe 6 — `gh` runs outside the sandbox\n\nTests whether `gh` can reach GitHub from a sandboxed Bash call, and if not, whether the `sandbox.excludedCommands: [\"gh *\"]` exclusion the framework reference relies on is in place.\nOn macOS a sandboxed `gh` cannot verify TLS or read the keychain (`x509: OSStatus -26276` \u002F `HTTP 401`), so only the exclusion makes it work.\nThe exclusion applies only when every segment of a Bash invocation is `cd …` or `gh …`.\n\nThe probe deliberately runs `gh` through `sh -c` so the exclusion cannot apply to it, showing what an *un-excluded* `gh` does on this machine.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-6-gh-outside-sandbox.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ gh works inside the sandbox` | Pass | Platform lets `gh` verify TLS and read its token inside the sandbox (typical on Linux). |\n| `✓ … \"gh *\" is in excludedCommands` | Pass | The known macOS shape, and the framework's exclusion is present. Calls still fail if they are not `cd`\u002F`gh`-only invocations — see the catalog entry. |\n| `✗ … NOT found in excludedCommands` | Fail | `gh` cannot work inside the sandbox on this machine and nothing runs it outside. |\n| `⚠ gh failed for another reason` | Warn | Not the catalogued shape (network down, not logged in, …); inspect the message. |\n| `⚠ catch-all \"Bash(gh *)\" in permissions.ask` | Warn | Ask beats allow regardless of specificity, so this rule prompts on every read-only `gh` call. Replace it with the explicit write-subcommand list from the reference `.claude\u002Fsettings.json`. Extra line, printed after the main result. |\n| `⊘ gh not on PATH` | Skip | `gh` not installed; not a sandbox restriction. |\n\n`~\u002F.claude\u002Fsettings.json` is usually unreadable from inside the sandbox, so the exclusion check may see only the project-scope files.\nIf the user keeps the exclusion at user scope, a ✗ here is a false alarm; say so when reporting.\n\nEven with the exclusion present, a `gh` call is excluded only when every part of the Bash invocation is `cd …` or `gh …`.\nA pipe, a `$(…)` substitution, a loop, or any file redirection (`> file`, even `> \u002Fdev\u002Fnull`) puts it back in the sandbox.\nThe redirection case is a Claude Code regression tracked in [anthropics\u002Fclaude-code#95532](https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-code\u002Fissues\u002F95532); the catalog entry shows the `gh tofile` alias that works around it.\nWhen the user reports a `gh` failure this probe does not reproduce, ask for the exact command line; the shape is usually the answer.\n\n**On ✗ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — `gh` fails with TLS `OSStatus -26276` or `HTTP 401` inside the sandbox](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#gh-fails-with-tls-osstatus--26276-or-http-401-inside-the-sandbox).\n\n### Probe 7 — `prek` and `uv` usable inside the sandbox\n\nTests whether the dev tools the framework's hooks and Python tools run on are found and can write their cache from a sandboxed Bash call.\nThey live in `~\u002F.local\u002Fbin`, which the harness reads only when the worktree's `.claude\u002Fsettings.local.json` grants it; the committed project-scope entries are not applied.\nInside the sandbox a read-denied directory looks exactly like an absent one, so the probe reads `settings.local.json` to tell a missing grant from a tool that is not installed.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-7-dev-tools.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ (found: …; ~\u002F.cache writable)` | Pass | `prek` \u002F `uv` run inside the sandbox and can write their caches. |\n| `✗ (found: …; ~\u002F.cache not writable …)` | Fail | The tools start but cannot write their cache or state. |\n| `⚠ (… not found; ~\u002F.local\u002Fbin is not in … settings.local.json)` | Warn | The grant is missing; the tools are most likely installed but hidden. |\n| `⊘ (… not found; ~\u002F.local\u002Fbin is granted …)` | Skip | The grant is present and neither tool is installed there; not a sandbox restriction. |\n\n**On ✗ or ⚠ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — `prek` or `uv` not found, or cannot write its cache, inside the sandbox](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#prek-or-uv-not-found-or-cannot-write-its-cache-inside-the-sandbox).\n\n### Probe 8 — Global git hook dir readable (whole-user scope)\n\nTests whether git run inside the sandbox can see the hooks a global `core.hooksPath` points at.\nGit treats a hook it cannot see as one that does not exist, so an unreadable hook dir costs every hook — `pre-commit` and `prek` included — without an error.\nOnly a look from inside the sandbox shows it, which is where this probe runs.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-8-git-hooks.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ (… readable; hooks visible: …)` | Pass | Sandboxed git runs the listed hooks. |\n| `✗ (core.hooksPath … not readable inside sandbox …)` | Fail | The hook dir is hidden; every sandboxed commit skips every hook. |\n| `✗ (… readable, but not the target of: …)` | Fail | The dir is visible but a hook's symlink target is not — typically hooks symlinked from a sync repo the sandbox does not grant. |\n| `⚠ (… holds none of pre-commit, commit-msg, pre-push, post-checkout)` | Warn | `core.hooksPath` is set to a dir with none of the common hooks; check it is the intended one. |\n| `⊘ (no global core.hooksPath …)` | Skip | Per-project scope: hooks live in each repo's `.git\u002Fhooks`, inside the project root. |\n\n**On ✗ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — Git hooks silently skipped for commits made inside the sandbox](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#git-hooks-silently-skipped-for-commits-made-inside-the-sandbox).\n\n### Probe 9 — Working directories under the read block\n\nTests whether, with `permissions.blockReadsOutsideWorkingDirectories` on, the scratch root `\u002Ftmp\u002Fclaude-\u003Cuid>` the skills read on every run is a working directory.\nWithout it nothing breaks, but each read there prompts, and a bulk sync multiplies that by its gatherer agents.\nIt also fails when `$HOME\u002F.claude\u002Fmagpie` (the fixed path the vetted-ops rules name) is one, read block or not: the sandbox makes working directories writable, and the vetted-ops commands run from there outside the sandbox.\nThe prompt comes before any command runs, so the [sandbox-error hint hook](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsecure-agent-setup.md#sandbox-error-hint-hook) never sees it; this probe is the only in-session pointer.\nWhere the vetted-ops dispatcher is used, a ✓ here is not enough: its commands spell `~` literally, which the read block cannot check, so every `vetted-op-read` call prompts while the block is on, and a background gatherer turns each prompt into a silent denial.\nThe setup requires the block off there ([Read-only vetted ops never prompt](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsecure-agent-setup.md#read-only-vetted-ops-never-prompt)); `setup-isolated-setup-verify` check 16 enforces it.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-9-working-dirs.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✗ … is a working directory overlapping …` | Fail | `$HOME\u002F.claude\u002Fmagpie`, a directory inside it, or a parent of it is listed, usually by an older `sandbox-add-project-root.sh`; re-run the updated script with `--all-worktrees` to remove it. |\n| `✓ … is a working directory` | Pass | The resolved scratch root is listed (normally in `.claude\u002Fsettings.local.json`, written by `sandbox-add-project-root.sh`). |\n| `⚠ not a working directory: …` | Warn | The scratch root is missing; reads under it prompt. |\n| `⚠ … the glob entry … is never matched` | Warn | A glob such as `\u002Ftmp\u002Fclaude-*` is listed as a working directory but does not match; replace it with the resolved path. |\n| `⊘ … blockReadsOutsideWorkingDirectories is off` | Skip | No read block, so nothing prompts. |\n| `⊘ HOME is not set` | Skip | The paths cannot be resolved; nothing to compare. |\n| `⊘ … user-scope settings unreadable from the sandbox` | Skip | The entries are missing from the readable project files, but the read block is usually set in user scope, which the sandbox cannot read; `setup-isolated-setup-verify` check 15 reads it from outside the sandbox. |\n\n**On ✗ or ⚠ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — Reads of `~\u002F.claude\u002Fmagpie` or `\u002Ftmp\u002Fclaude-\u003Cuid>` ask for approval every time](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#reads-of-claudemagpie-or-tmpclaude-uid-ask-for-approval-every-time).\n\n## After the report\n\nIf every probe is ✓ or ⊘:\n\n> All nine probes pass (or are not applicable). The sandbox is\n> not currently blocking the known failure modes catalogued in\n> `docs\u002Fsetup\u002Fsandbox-troubleshooting.md`. If you hit a different\n> sandbox-shaped failure, follow the catalog's *Adding a new\n> entry* section and (optionally) extend this skill with another\n> probe so future runs catch the same shape automatically.\n\nIf any probe is ✗:\n\n1. Surface every fail in one report (do not stop at the first).\n2. For each fail, print the troubleshooting-doc anchor link from the probe's *On ✗ → remediation* line above.\n3. Suggest the user read the catalog entry's symptom → root cause → fix, then apply the settings.json widening themselves.\n   Do **not** propose to apply the widening from this skill; settings.json widenings are sandbox-bypass-adjacent and need an explicit user-driven edit.\n4. After the user has applied the widening (in a separate flow), re-run `setup-isolated-setup-doctor` to confirm the probe now passes.\n\nIf a probe surfaces a fail shape not catalogued in\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md`](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md):\n\n1. Report the fail with the literal probe command + exit code + stderr.\n2. Suggest the user add a new entry to the catalog per its *Adding a new entry* section (symptom verbatim, root cause, fix, notes).\n3. Once the catalog has the new entry, extend this skill with a matching probe in the same shape so the next doctor run catches it automatically.\n\n## Adding a probe\n\nWhen the troubleshooting catalogue grows an entry, add a matching probe:\n[`scripts\u002FREADME.md`](scripts\u002FREADME.md).\n","\u003C!-- Placeholder convention (see AGENTS.md#placeholder-convention-used-in-skill-files):\n     \u003Cproject-config> → per file: the personal layer, else `.apache-magpie-overrides\u002F` -->\n\n# setup-isolated-setup-doctor\n\n## Runtime routing (run before the Claude-specific probes)\n\nUse the operator's explicitly requested runtime when supplied; otherwise use the active session's runtime.\nAn installed executable or configuration directory alone does not select a runtime.\nFor the routing below, treat that selection as the active harness.\n\nWhen the active harness is Codex, first require the static verification in [docs\u002Fadapters\u002Fcodex.md](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fadapters\u002Fcodex.md#verify), then run the shared live environment probes inside the active Codex sandbox.\nAttribute failures separately to native sandbox\u002Fnetwork denial, approval policy, or the POSIX agent-iso layer.\nDo not prescribe a `.claude` settings change for a Codex failure.\nThen stop before the Claude-specific branch below.\n\nWhen the selected runtime is Antigravity, follow\n[docs\u002Fadapters\u002Fantigravity.md](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fadapters\u002Fantigravity.md#doctor): verify the user-scope profile first, then diagnose the actual tool result in the active Antigravity session.\nDistinguish sandbox limits, permission-rule denials, guard-hook failures, and wrapper or authentication problems.\nDo not require Claude configuration or prescribe Claude settings changes; then stop before the Claude-specific probes below.\n\nWhen the selected runtime is Goose, follow\n[docs\u002Fadapters\u002Fgoose.md](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fadapters\u002Fgoose.md#doctor): verify the plugin, its sandbox runtime and the launcher first, then diagnose the actual tool result in the active Goose session.\nDistinguish sandbox limits or a missing sandbox runtime, hook denials (deny rules or the guard), a hook that failed closed, approve-mode declines, and wrapper or provider-key problems.\nDo not require Claude configuration or prescribe Claude settings changes; then stop before the Claude-specific probes below.\n\nWhen the selected runtime is Pi, follow\n[docs\u002Fadapters\u002Fpi.md](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fadapters\u002Fpi.md#doctor): verify the package install first, then diagnose the actual tool result in the active Pi session.\nDistinguish sandbox limits or a sandbox that could not start, permission-rule denials, guard denials, and wrapper or authentication problems.\nDo not require Claude configuration or prescribe Claude settings changes; then stop before the Claude-specific probes below.\n\nWhen the selected runtime is Copilot CLI, follow [docs\u002Fadapters\u002Fcopilot.md](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fadapters\u002Fcopilot.md#doctor): verify the hook first, then diagnose the actual tool result in the live session.\n\nWhen the harness is Claude Code, continue below.\nIf the harness cannot be determined, ask once.\n\nThis is the diagnostic layer over the secure agent setup.\n[`verify`](..\u002Fisolated-setup-verify\u002FSKILL.md) checks statically that the setup is *installed* right, catching drift and missing pieces.\nThis skill checks whether common workflows are *functionally blocked* by the sandbox as configured, catching over-restrictive allowlists.\n([`install`](..\u002Fisolated-setup-install\u002FSKILL.md) puts the setup in place; [`update`](..\u002Fisolated-setup-update\u002FSKILL.md) reports framework drift.)\n\nRun `verify` first when the install itself is in doubt: fresh machine, recent upgrade, sandbox-state surprise.\nRun `doctor` when the install is known good and a workflow fails in a sandbox-shaped way: agent unreachable, socket error, port permission error.\n\nEvery probe maps to a numbered entry in [`docs\u002Fsetup\u002Fsandbox-troubleshooting.md`](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md).\nThe doctor identifies *which* entry applies now; it does not re-explain the remediation.\nIf a fail shows a failure mode not catalogued there, propose appending a new entry per the catalog's *Adding a new entry* section.\n\n## Golden rules\n\n- **Read-only.** Each probe is a small, deterministic, side-effect-free check.\n  The skill **never** edits a settings file, **never** runs a command with `dangerouslyDisableSandbox`, and **never** installs anything.\n  If a check fails, surface it and point at the catalog entry; do not auto-fix.\n- **Run every probe, even on early failure.** Do not stop at the first ✗.\n  A user may have one of eight independent restrictions or all eight, and finding them one re-run at a time is annoying.\n- **Distinguish ✗ (failing) from ⊘ (not applicable).** ✗ means the probe ran and the sandbox blocked it.\n  ⊘ means the probe was skipped because a prerequisite is absent (e.g. no `docker` \u002F `podman` on `PATH` → docker probe ⊘, not ✗).\n- **Surface evidence.** Each report line names the probe command, the exit code, and the relevant stderr snippet.\n  \"Looks blocked\" is not useful; \"ssh-add -l → rc=2 → `Could not open a connection to your authentication agent`\" is.\n- **Sandbox placeholders are not files.** Inside the Claude Code sandbox a denied path that does not exist on the host can appear as a `\u002Fdev\u002Fnull` bind mount: `stat -c '%F %t,%T' \u003Cpath>` prints `character special file 1,3`.\n  `git status` lists such placeholders as untracked (`.bash_profile`, `.claude\u002Fsettings.json`, `.mcp.json`), and reading one returns nothing.\n  Take the host state from git (`git ls-files \u003Cpath>`, `git log -- \u003Cpath>`) or from a read the user runs outside the sandbox, and never delete the placeholder.\n- **Map each ✗ to a catalog entry.** The fail report links directly to the matching section of [`docs\u002Fsetup\u002Fsandbox-troubleshooting.md`](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md).\n  Do not paraphrase the remediation; the catalog is the single source of truth.\n\n## The probes\n\nThe probes cover the catalog's failure modes that a sandboxed command can detect on its own; the signing entries that need a live touch or a terminal are verified by `setup-isolated-setup-verify` check 10 instead.\nNew probes are added when new entries land in the catalog, so the two stay in lock-step.\n\n### Probe 1 — SSH agent \u002F Yubikey reachable\n\nTests whether `ssh-agent` is reachable from inside the sandbox.\nTwo failure modes:\n`SSH_AUTH_SOCK` passes through `claude-iso`'s env whitelist but the socket file is not in `sandbox.filesystem.allowRead`, so the agent's `ssh` \u002F `git push` subprocesses cannot even `stat(2)` it;\nor, on macOS, the file is readable but its path is missing from `sandbox.network.allowUnixSockets`, so `connect(2)` is denied and the agent looks unreachable while the socket is plainly there.\nA signed commit hits the second as `No private key found for public key`.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-1-ssh-agent.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ N identities listed` | Pass | `ssh-add -l` returned the key list. |\n| `✓ agent reachable, no identities` | Pass | `ssh-add -l` returned rc=1 (the documented \"no keys\" exit). |\n| `✗ socket not stat-able` | Fail | Sandbox blocks `stat(2)` on the socket file. |\n| `✗ agent unreachable` | Fail | Sandbox blocks `connect(2)` to the socket. |\n| `⊘ SSH_AUTH_SOCK not set` | Skip | Either the user does not run `ssh-agent`, or `claude-iso`'s env whitelist dropped it (separate bug — verify). |\n\n**On ✗ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — SSH agent \u002F Yubikey appears unreachable from inside the sandbox](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#ssh-agent--yubikey-appears-unreachable-from-inside-the-sandbox).\n\n### Probe 2 — Localhost port bind\n\nTests whether a process inside the sandbox can bind to a loopback port AND then talk to itself over loopback.\nThe catalog documents the second half failing (egress proxy blocks `127.0.0.1`).\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-2-localhost-bind.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ bound + loopback GET → HTTP 200` | Pass | Both bind and loopback HTTP work. |\n| `✗ bind: [Errno 1] Operation not permitted` | Fail | The sandbox refuses listening sockets outright; `sandbox.network.allowLocalBinding` is unset. Fails before any egress rule is consulted, so `allowedDomains` changes do not help. |\n| `✗ bind: ...` (other errno) | Fail | The sandbox blocks `bind(2)` on `127.0.0.1` for another reason. Rare; report the literal error. |\n| `✗ bind ok, loopback GET: ...` | Fail | Bind works but the sandbox egress proxy refuses `127.0.0.1` as a destination. Common shape. |\n\n**On ✗ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — Test cannot bind to a localhost port](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#test-cannot-bind-to-a-localhost-port).\n\n### Probe 3 — Podman \u002F Docker through the container gateway\n\nTests whether the runtime CLI can talk to the [container gateway](..\u002F..\u002F..\u002F..\u002Ftools\u002Fcontainer-gateway\u002FREADME.md), not the real daemon socket; the sandbox never gets a route to the daemon itself.\nRun it for each of `podman` \u002F `docker` on `PATH`; ⊘ each one not installed (an absent prerequisite, not a sandbox failure).\nThe remaining checks narrow down which of the three wiring pieces (env var, running gateway, allowed socket) is missing, in the order a fresh install would hit them.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-3-container-gateway.sh\n```\n\n`status_json` comes from the gateway's own read-only `status` subcommand.\nThe doctor may call it from inside the sandbox, since it neither binds a socket nor touches the daemon.\n`gw_src` picks the adopter's pinned snapshot (`.apache-magpie\u002Ftools\u002Fcontainer-gateway\u002Fsrc`) when present, else the framework repo's own tree (`tools\u002Fcontainer-gateway\u002Fsrc`), else the operator install the `SessionStart` hook runs (`~\u002F.claude\u002Fscripts\u002Fcontainer-gateway\u002Fsrc`), so the same probe runs in an adopted checkout, in this framework's own worktree and on a marketplace install.\nThe operator install is readable inside the sandbox only when the project's gateway wiring grants `~\u002F.claude\u002Fscripts\u002Fcontainer-gateway\u002F` in `sandbox.filesystem.allowRead`; without it the directory is visible but its files are not, so the probe checks a file before calling `status`.\nOnly `status` can vouch that the socket is the gateway's — a raw daemon socket answers `\u003Crt> info` just as well — so with no status (no gateway source, or one the `PATH` `python3` cannot import) the probe fails rather than trusting the socket.\nA `status` that exits 2 without a report has refused the run directory.\nThe `gw_state` check runs **before** the raw socket-file test.\nA backend that `status` does not list under `serving` never gets a socket file, so testing `-S \"$sock\"` first would misreport \"gateway not running\" for the \"running, but this backend's machine\u002Fdaemon is down\" case.\nThe `-S` test is a defensive fallback for an already-serving backend whose socket vanished mid-probe, not the primary check.\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ \u003Crt> reaches the container gateway at \u003Csock>` | Pass | CLI → gateway → daemon all answer. |\n| `✗ … unset — gateway not wired into settings` | Fail | The reference `env` block is missing from project settings. |\n| `✗ gateway socket missing` | Fail | The `SessionStart` hook did not start the gateway, or it exited and no `PreToolUse` `ensure` hook started it again before the probe's container command (check 12a of `setup-isolated-setup-verify` flags a missing one); check `container-gateway.log` in the gateway's run directory — `\u003Cproject>\u002F.apache-magpie-local\u002Frun\u002F` when adopted, else `\u003Cgit-common-dir>\u002Fapache-magpie\u002Frun\u002F\u003Cworktree-id>\u002F`. |\n| `✗ gateway status refused the run directory` | Fail | `status` exited 2 without a report: a run-directory component is a symlink or has the wrong owner, type or mode. Inspect the run directory from outside the sandbox; do not point the CLI around it. |\n| `✗ gateway status unavailable` | Fail | The probe could not get a report from `status`: no gateway source was found (install the operator copy, install Step L.1), the operator copy is not readable inside the sandbox (`gateway source at … is not readable`: the `allowRead` grant in the project's gateway wiring is missing), or `status` exited without one (`rc=N`; typically a `python3` on `PATH` too old to import the gateway). The socket may still work, but nothing confirms it is the gateway's. |\n| `✗ gateway running without a \u003Crt> backend` | Fail | `status` reports the gateway up but `serving` does not list this CLI's backend — the Podman machine or Docker daemon behind it is not running. Start it from outside the sandbox, then restart the gateway. |\n| `✗ connect … denied` | Fail | The gateway socket is not in `sandbox.network.allowUnixSockets`. |\n| `✗ gateway up, backend down` | Fail | Podman machine \u002F Docker not running on the host; start it from your own terminal. |\n| `✗ no response in 15s — \u003Crt> info hung` | Fail | `_probe_timeout` killed a stalled `\u003Crt> info` call; the backend daemon behind the gateway is likely wedged — restart it from outside the sandbox. |\n| `⊘ \u003Crt> not on PATH` | Skip | Runtime not installed; not a sandbox restriction. |\n\nAn empty `podman machine list` from inside the sandbox is a read denial on the machine's directory, not proof that no machine exists.\nDecide the machine's real state from outside the sandbox, per the catalog entry below.\n\n**On ✗ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — Docker \u002F Podman command fails with a socket error](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#docker--podman-command-fails-with-a-socket-error).\n\n### Probe 4 — Per-project scratch directory (`TMPDIR`)\n\nTests whether the session has a **writable** scratch directory.\nThe sandbox mounts the host `\u002Ftmp` read-only and makes only specific subpaths writable, so a session whose `TMPDIR` falls back to `\u002Ftmp` has no scratch area at all.\n\n`TMPDIR` landing on the shared session root rather than a per-project directory is **not** a finding.\nClaude Code sets `TMPDIR` itself when it builds the sandbox, and that wins over `env.TMPDIR` from any settings file, so the shared root is expected and no configuration changes it.\nEach session still gets a per-project, per-session scratchpad beneath it.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-4-scratch-dir.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ per-project + writable` | Pass | `TMPDIR` resolves under this project's path slug and accepts writes. |\n| `✓ writable; shared session root` | Pass | The expected value on current Claude Code. Every project on the machine shares this directory, so write through the per-session scratchpad beneath it, or use unique filenames — but there is nothing to fix. |\n| `✗ TMPDIR not set` | Fail | Tooling falls back to `\u002Ftmp`, which is read-only inside the sandbox. |\n| `✗ directory missing` | Fail | `TMPDIR` names a path nothing has created yet. |\n| `✗ not writable inside sandbox` | Fail | `TMPDIR` points outside `sandbox.filesystem.allowWrite`. |\n\n**On ✗ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — Temp files fail with \"Read-only file system\" under `\u002Ftmp`](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#temp-files-fail-with-read-only-file-system-under-tmp).\n\nDo **not** propose `env.TMPDIR` in a settings file as the fix.\nClaude Code overrides it when it builds the sandbox, so the setting is accepted and silently has no effect.\nThe giveaway is a directory that exists, is named exactly as configured, and stays empty.\nThe catalog entry above covers what is actually actionable.\n\n### Probe 5 — Signing key readable (`gpg.format=ssh`)\n\nTests whether the public key git hands to `ssh-keygen -Y sign` can be opened from inside the sandbox.\nFailure mode: the framework denies `~\u002F.ssh\u002F` wholesale, so with `gpg.format=ssh` every signed commit fails before the hardware key asks for a touch.\nThe touch overlay, which waits for `ssh-keygen` to block, never sees it block.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-5-signing-key.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ readable inside sandbox` | Pass | `ssh-keygen` will be able to open the public key. |\n| `✓ literal key` | Pass | `user.signingkey` holds the key text itself; no file is involved. |\n| `✗ not readable inside sandbox` | Fail | The sandbox's `~\u002F.ssh\u002F` read deny covers the public key; add that one file to `allowRead`. |\n| `⊘ gpg.format is not ssh` | Skip | Signing goes through gpg (or is off); the agent-socket rules behind Probe 1 are what matter. |\n| `⊘ user.signingkey unset` | Skip | Misconfigured signing, not a sandbox problem — mention it, do not fail the probe. |\n| `signing-program → ✓` | Pass | git's signing program (the touch overlay's `gpg-touch-wrap-*` wrapper, or whatever `gpg.ssh.program` \u002F `gpg.program` names) can be started from inside the sandbox. Nothing printed when neither key is set: git uses its default `ssh-keygen` \u002F `gpg` from `PATH`. |\n| `signing-program → ✗` | Fail | The program git is configured to sign with is read-denied inside the sandbox — for the overlay wrapper, `~\u002F.claude\u002Fscripts\u002F` is. Every sandboxed signed commit fails at once with `cannot exec`; add the wrapper's two files to `allowRead`. |\n\n**On ✗ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — Signed commit fails before any touch when git signs with ssh](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#signed-commit-fails-before-any-touch-when-git-signs-with-ssh)\nfor the key, and\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — Signed commit fails with \"cannot exec\" of the touch-overlay wrapper](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#signed-commit-fails-with-cannot-exec-of-the-touch-overlay-wrapper)\nfor the program.\n\n### Probe 6 — `gh` runs outside the sandbox\n\nTests whether `gh` can reach GitHub from a sandboxed Bash call, and if not, whether the `sandbox.excludedCommands: [\"gh *\"]` exclusion the framework reference relies on is in place.\nOn macOS a sandboxed `gh` cannot verify TLS or read the keychain (`x509: OSStatus -26276` \u002F `HTTP 401`), so only the exclusion makes it work.\nThe exclusion applies only when every segment of a Bash invocation is `cd …` or `gh …`.\n\nThe probe deliberately runs `gh` through `sh -c` so the exclusion cannot apply to it, showing what an *un-excluded* `gh` does on this machine.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-6-gh-outside-sandbox.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ gh works inside the sandbox` | Pass | Platform lets `gh` verify TLS and read its token inside the sandbox (typical on Linux). |\n| `✓ … \"gh *\" is in excludedCommands` | Pass | The known macOS shape, and the framework's exclusion is present. Calls still fail if they are not `cd`\u002F`gh`-only invocations — see the catalog entry. |\n| `✗ … NOT found in excludedCommands` | Fail | `gh` cannot work inside the sandbox on this machine and nothing runs it outside. |\n| `⚠ gh failed for another reason` | Warn | Not the catalogued shape (network down, not logged in, …); inspect the message. |\n| `⚠ catch-all \"Bash(gh *)\" in permissions.ask` | Warn | Ask beats allow regardless of specificity, so this rule prompts on every read-only `gh` call. Replace it with the explicit write-subcommand list from the reference `.claude\u002Fsettings.json`. Extra line, printed after the main result. |\n| `⊘ gh not on PATH` | Skip | `gh` not installed; not a sandbox restriction. |\n\n`~\u002F.claude\u002Fsettings.json` is usually unreadable from inside the sandbox, so the exclusion check may see only the project-scope files.\nIf the user keeps the exclusion at user scope, a ✗ here is a false alarm; say so when reporting.\n\nEven with the exclusion present, a `gh` call is excluded only when every part of the Bash invocation is `cd …` or `gh …`.\nA pipe, a `$(…)` substitution, a loop, or any file redirection (`> file`, even `> \u002Fdev\u002Fnull`) puts it back in the sandbox.\nThe redirection case is a Claude Code regression tracked in [anthropics\u002Fclaude-code#95532](https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-code\u002Fissues\u002F95532); the catalog entry shows the `gh tofile` alias that works around it.\nWhen the user reports a `gh` failure this probe does not reproduce, ask for the exact command line; the shape is usually the answer.\n\n**On ✗ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — `gh` fails with TLS `OSStatus -26276` or `HTTP 401` inside the sandbox](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#gh-fails-with-tls-osstatus--26276-or-http-401-inside-the-sandbox).\n\n### Probe 7 — `prek` and `uv` usable inside the sandbox\n\nTests whether the dev tools the framework's hooks and Python tools run on are found and can write their cache from a sandboxed Bash call.\nThey live in `~\u002F.local\u002Fbin`, which the harness reads only when the worktree's `.claude\u002Fsettings.local.json` grants it; the committed project-scope entries are not applied.\nInside the sandbox a read-denied directory looks exactly like an absent one, so the probe reads `settings.local.json` to tell a missing grant from a tool that is not installed.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-7-dev-tools.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ (found: …; ~\u002F.cache writable)` | Pass | `prek` \u002F `uv` run inside the sandbox and can write their caches. |\n| `✗ (found: …; ~\u002F.cache not writable …)` | Fail | The tools start but cannot write their cache or state. |\n| `⚠ (… not found; ~\u002F.local\u002Fbin is not in … settings.local.json)` | Warn | The grant is missing; the tools are most likely installed but hidden. |\n| `⊘ (… not found; ~\u002F.local\u002Fbin is granted …)` | Skip | The grant is present and neither tool is installed there; not a sandbox restriction. |\n\n**On ✗ or ⚠ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — `prek` or `uv` not found, or cannot write its cache, inside the sandbox](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#prek-or-uv-not-found-or-cannot-write-its-cache-inside-the-sandbox).\n\n### Probe 8 — Global git hook dir readable (whole-user scope)\n\nTests whether git run inside the sandbox can see the hooks a global `core.hooksPath` points at.\nGit treats a hook it cannot see as one that does not exist, so an unreadable hook dir costs every hook — `pre-commit` and `prek` included — without an error.\nOnly a look from inside the sandbox shows it, which is where this probe runs.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-8-git-hooks.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✓ (… readable; hooks visible: …)` | Pass | Sandboxed git runs the listed hooks. |\n| `✗ (core.hooksPath … not readable inside sandbox …)` | Fail | The hook dir is hidden; every sandboxed commit skips every hook. |\n| `✗ (… readable, but not the target of: …)` | Fail | The dir is visible but a hook's symlink target is not — typically hooks symlinked from a sync repo the sandbox does not grant. |\n| `⚠ (… holds none of pre-commit, commit-msg, pre-push, post-checkout)` | Warn | `core.hooksPath` is set to a dir with none of the common hooks; check it is the intended one. |\n| `⊘ (no global core.hooksPath …)` | Skip | Per-project scope: hooks live in each repo's `.git\u002Fhooks`, inside the project root. |\n\n**On ✗ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — Git hooks silently skipped for commits made inside the sandbox](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#git-hooks-silently-skipped-for-commits-made-inside-the-sandbox).\n\n### Probe 9 — Working directories under the read block\n\nTests whether, with `permissions.blockReadsOutsideWorkingDirectories` on, the scratch root `\u002Ftmp\u002Fclaude-\u003Cuid>` the skills read on every run is a working directory.\nWithout it nothing breaks, but each read there prompts, and a bulk sync multiplies that by its gatherer agents.\nIt also fails when `$HOME\u002F.claude\u002Fmagpie` (the fixed path the vetted-ops rules name) is one, read block or not: the sandbox makes working directories writable, and the vetted-ops commands run from there outside the sandbox.\nThe prompt comes before any command runs, so the [sandbox-error hint hook](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsecure-agent-setup.md#sandbox-error-hint-hook) never sees it; this probe is the only in-session pointer.\nWhere the vetted-ops dispatcher is used, a ✓ here is not enough: its commands spell `~` literally, which the read block cannot check, so every `vetted-op-read` call prompts while the block is on, and a background gatherer turns each prompt into a silent denial.\nThe setup requires the block off there ([Read-only vetted ops never prompt](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsecure-agent-setup.md#read-only-vetted-ops-never-prompt)); `setup-isolated-setup-verify` check 16 enforces it.\n\n**Command:**\n\n```bash\nbash \u003Cskill-dir>\u002Fscripts\u002Fprobe-9-working-dirs.sh\n```\n\n**Interpretation:**\n\n| Result | Status | Meaning |\n|---|---|---|\n| `✗ … is a working directory overlapping …` | Fail | `$HOME\u002F.claude\u002Fmagpie`, a directory inside it, or a parent of it is listed, usually by an older `sandbox-add-project-root.sh`; re-run the updated script with `--all-worktrees` to remove it. |\n| `✓ … is a working directory` | Pass | The resolved scratch root is listed (normally in `.claude\u002Fsettings.local.json`, written by `sandbox-add-project-root.sh`). |\n| `⚠ not a working directory: …` | Warn | The scratch root is missing; reads under it prompt. |\n| `⚠ … the glob entry … is never matched` | Warn | A glob such as `\u002Ftmp\u002Fclaude-*` is listed as a working directory but does not match; replace it with the resolved path. |\n| `⊘ … blockReadsOutsideWorkingDirectories is off` | Skip | No read block, so nothing prompts. |\n| `⊘ HOME is not set` | Skip | The paths cannot be resolved; nothing to compare. |\n| `⊘ … user-scope settings unreadable from the sandbox` | Skip | The entries are missing from the readable project files, but the read block is usually set in user scope, which the sandbox cannot read; `setup-isolated-setup-verify` check 15 reads it from outside the sandbox. |\n\n**On ✗ or ⚠ → remediation:**\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md` — Reads of `~\u002F.claude\u002Fmagpie` or `\u002Ftmp\u002Fclaude-\u003Cuid>` ask for approval every time](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md#reads-of-claudemagpie-or-tmpclaude-uid-ask-for-approval-every-time).\n\n## After the report\n\nIf every probe is ✓ or ⊘:\n\n> All nine probes pass (or are not applicable). The sandbox is\n> not currently blocking the known failure modes catalogued in\n> `docs\u002Fsetup\u002Fsandbox-troubleshooting.md`. If you hit a different\n> sandbox-shaped failure, follow the catalog's *Adding a new\n> entry* section and (optionally) extend this skill with another\n> probe so future runs catch the same shape automatically.\n\nIf any probe is ✗:\n\n1. Surface every fail in one report (do not stop at the first).\n2. For each fail, print the troubleshooting-doc anchor link from the probe's *On ✗ → remediation* line above.\n3. Suggest the user read the catalog entry's symptom → root cause → fix, then apply the settings.json widening themselves.\n   Do **not** propose to apply the widening from this skill; settings.json widenings are sandbox-bypass-adjacent and need an explicit user-driven edit.\n4. After the user has applied the widening (in a separate flow), re-run `setup-isolated-setup-doctor` to confirm the probe now passes.\n\nIf a probe surfaces a fail shape not catalogued in\n[`docs\u002Fsetup\u002Fsandbox-troubleshooting.md`](..\u002F..\u002F..\u002F..\u002Fdocs\u002Fsetup\u002Fsandbox-troubleshooting.md):\n\n1. Report the fail with the literal probe command + exit code + stderr.\n2. Suggest the user add a new entry to the catalog per its *Adding a new entry* section (symptom verbatim, root cause, fix, notes).\n3. Once the catalog has the new entry, extend this skill with a matching probe in the same shape so the next doctor run catches it automatically.\n\n## Adding a probe\n\nWhen the troubleshooting catalogue grows an entry, add a matching probe:\n[`scripts\u002FREADME.md`](scripts\u002FREADME.md).\n",{"mode":43,"name":5,"family":25,"license":15,"capability":54,"description":7,"when_to_use":57,"surface_hash":58,"measured_tokens":59},[55,56],"capability:platform","capability:reassess","When the user says \"doctor my sandbox\", \"why is the sandbox blocking X\", or reports a failure that smells sandbox-shaped — agent unreachable, socket errors, permission errors on a port. Also worth running after an agent harness upgrade, since the sandbox profile moves.","sha256:f8a5db3da24024cb",7041,"main","ae04917d004c814d91fb486727282cf7d8e42196","plugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor",126,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie","https:\u002F\u002Fmagpie.apache.org\u002F","https:\u002F\u002Fgithub.com\u002Fapache","https:\u002F\u002Fwww.apache.org\u002F","2026-11-12 03:10:36",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add apache\u002Fmagpie --skill isolated-setup-doctor",{"tool":75,"command":76},"bunx","bunx skills add apache\u002Fmagpie --skill isolated-setup-doctor",{"tool":78,"command":79},"pnpm","pnpm dlx skills add apache\u002Fmagpie --skill isolated-setup-doctor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002FSKILL.md",true,[83,89,93,97,101,105,109,113,117,121,125,129,133,137],{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"scripts\u002Fprobe-1-ssh-agent.sh","SCRIPT","脚本",1695,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002Fscripts\u002Fprobe-1-ssh-agent.sh",{"path":90,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":91,"sourceHtmlUrl":92},"scripts\u002Fprobe-2-localhost-bind.sh",1863,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002Fscripts\u002Fprobe-2-localhost-bind.sh",{"path":94,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":95,"sourceHtmlUrl":96},"scripts\u002Fprobe-3-container-gateway.sh",7495,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002Fscripts\u002Fprobe-3-container-gateway.sh",{"path":98,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":99,"sourceHtmlUrl":100},"scripts\u002Fprobe-4-scratch-dir.sh",1458,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002Fscripts\u002Fprobe-4-scratch-dir.sh",{"path":102,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":103,"sourceHtmlUrl":104},"scripts\u002Fprobe-5-signing-key.sh",2122,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002Fscripts\u002Fprobe-5-signing-key.sh",{"path":106,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":107,"sourceHtmlUrl":108},"scripts\u002Fprobe-6-gh-outside-sandbox.sh",2210,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002Fscripts\u002Fprobe-6-gh-outside-sandbox.sh",{"path":110,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":111,"sourceHtmlUrl":112},"scripts\u002Fprobe-7-dev-tools.sh",2321,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002Fscripts\u002Fprobe-7-dev-tools.sh",{"path":114,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":115,"sourceHtmlUrl":116},"scripts\u002Fprobe-8-git-hooks.sh",2254,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002Fscripts\u002Fprobe-8-git-hooks.sh",{"path":118,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":119,"sourceHtmlUrl":120},"scripts\u002Fprobe-9-working-dirs.sh",3838,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002Fscripts\u002Fprobe-9-working-dirs.sh",{"path":122,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":123,"sourceHtmlUrl":124},"scripts\u002FREADME.md",1719,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002Fscripts\u002FREADME.md",{"path":126,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":127,"sourceHtmlUrl":128},"tests\u002Fhelpers.py",3209,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002Ftests\u002Fhelpers.py",{"path":130,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":131,"sourceHtmlUrl":132},"tests\u002Ftest_probe_1_ssh_agent.py",4348,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002Ftests\u002Ftest_probe_1_ssh_agent.py",{"path":134,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":135,"sourceHtmlUrl":136},"tests\u002Ftest_probe_3_container_gateway.py",10702,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002Ftests\u002Ftest_probe_3_container_gateway.py",{"path":138,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":139,"sourceHtmlUrl":140},"tests\u002Ftest_probe_5_signing_key.py",4570,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fisolated-setup-doctor\u002Ftests\u002Ftest_probe_5_signing_key.py",[142,166,190,211,237,257],{"skillNo":143,"name":39,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":49},"01M70JNYMCY5EEWYWDN30WKDJ4","Upgrade Magpie in one run: move to the new version if needed (`setup update`), check this machine and project, apply one approved plan, re-check, and print exact commands for what is out of reach.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-setup\u002Fskills\u002Fupgrade\u002FSKILL.md",[],[39,148,149,150,151,152,153,154,43,155,156,157,158,159,160,161,162,163,164,165],"notice","platform","for","project","re","move","session","machine","yes","new","version","apply","print","check","last","plan","run","update",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":49},"01M70JJBSW3XE35BAXQ1VTA9SV","dependency-vulnerability-audit","Read-only dependency vulnerability audit for one repository or a local\ncheckout. Detects the project's dependency manager(s), runs the\nappropriate audit tool, surfaces patchable findings grouped by severity,\nand proposes upgrades for maintainer review. Never modifies manifests or\nlock files and never opens update PRs.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-repo-health\u002Fskills\u002Fdependency-vulnerability-audit\u002FSKILL.md",[],[173,174,175,176,177,178,179,180,151,181,182,41,183,184,185,28,186,187,188,189],"vulnerability","audit","dependency","dependency vulnerability audit","never","checkout","chain","scope","dependency manager","local","files","invoke","manifests","ask","patch","hand","review",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":196,"publishedAt":49},"01M70JGBWHKMB7V6T7QWT6G5DQ","thread-mentor","Draft a teaching-register comment on a GitHub issue or PR thread on the\nconfigured `\u003Cupstream>` repo, aimed at a contributor missing context the\nmaintainer would spell out. Reads the thread, decides\nwhether an intervention is warranted, drafts one comment per the tone\nguide and convention pointers, and waits for explicit confirmation before\nposting via `gh`. Escalates on the four hand-off triggers.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-pr-management\u002Fskills\u002Fthread-mentor\u002FSKILL.md",[],[197,198,199,151,200,201,184,202,203,28,204,186,205,188,189,206,207,208,209,210],"thread mentor","mentor","thread","repro","confirmation","pr-management","contributor","number","teaching","at","config","drafts","flags","spell",{"skillNo":212,"name":213,"nameZh":6,"description":214,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":215,"categories":216,"keywords":222,"publishedAt":49},"01M70JF866SAVGXSSC33HRX4ZG","merge-candidates","Identify trivial, low-risk PRs in the `ready for maintainer review` queue\nof \u003Cupstream> that pass every quality gate and touch only supplementary\nareas (docs, changelog, translations, tests) — the \"express lane\".\nSurfaces and ranks candidates with per-PR diff summaries, an\nall-gates-green attestation, and the exact merge command. On explicit\nper-PR confirmation it can submit an APPROVE review, exactly as\npr-management-code-review does. It never merges itself — automated merge\nis the deliberately-deferred Agentic Autonomous mode.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-pr-management\u002Fskills\u002Fmerge-candidates\u002FSKILL.md",[217],{"categoryNo":218,"categoryName":219,"taxonomyType":220,"taxonomyTypeDesc":221},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[223,224,225,226,227,177,228,229,151,230,231,232,41,233,201,184,202,234,235,236],"merge candidates","merge","ready","quick","show","green","submit","churn","attestation","mode","autonomous","show me","agentic","code",{"skillNo":238,"name":239,"nameZh":6,"description":240,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":241,"categories":242,"keywords":243,"publishedAt":49},"01M6AD18GMVM1BEM31VF538R8A","generate-cve-json","Generate a CVE 5.x JSON document from an \u003Ctracker> tracking\nissue, ready to paste into the Vulnogram `#source` tab of the ASF CVE tool\nat https:\u002F\u002Fcveprocess.apache.org\u002Fcve5\u002F\u003CCVE-ID>#source. The conversion is\ndeterministic: same issue in, same JSON bytes out. Handles multiple\ncredits (one per line) and multiple references (URLs extracted from the\nissue's \"Public advisory URL\" and \"PR with the fix\" fields; the\n\"Security mailing list thread\" field is treated as internal-only and\nnever exported).","https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Ftools\u002Fcve-tool-vulnogram\u002Fgenerate-cve-json\u002FSKILL.md",[],[244,245,246,247,9,165,225,177,42,41,248,249,250,251,252,253,254,255,256,206,184,28],"cve","generate","generate cve json","json","either","URL","team","conversion","publish","references","tracker","paste","exported",{"skillNo":258,"name":259,"nameZh":6,"description":260,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":261,"categories":262,"keywords":264,"publishedAt":49},"01M6AD158PEPPPX9N33DASMRQ8","write-skill","Write a new skill for the Apache Magpie framework, or bring an existing one up to current conventions. Scaffolds the directory, walks the house style and the prompt-injection defences, and validates before it ships.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fmagpie\u002Fblob\u002Fmain\u002Fplugins\u002Fmagpie-utilities\u002Fskills\u002Fwrite-skill\u002FSKILL.md",[263],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[265,266,267,9,46,268,43,269,157,28,270,271,272,273,274,275,276,277,278,279],"write skill","write","create","framework","up","optimize","authoring","injection","Utilities","new skill","magpie","add","existing skill","capability","bring"]