一键在 Manus 中运行任何 Skill

shell-pinned-to-deleted-worktree-cwd-blocks-git

星标2

分支0

更新时间2026年7月8日 11:09

Diagnoses + recovers the "every shell command now fails `fatal: Unable to read current working directory: Operation not permitted`" trap, which appears AFTER a git worktree you were running commands in gets removed/pruned mid-session (you merged + deleted its branch, ran `git worktree remove`, or the Claude Code harness auto-cleaned a merged/unchanged worktree). Use when: (1) git AND python both error `Operation not permitted` / `PermissionError: [Errno 1] Operation not permitted` on startup; (2) `cd /valid/abs/path && pwd` PRINTS the valid path but the very next `git`/`python` in the SAME command still fails (pwd lies); (3) the harness prints "Shell cwd was reset to <some-.claude/worktrees/...>" after each Bash call; (4) `git -C /repo`, recreating the dir with `mkdir`, `python3 -c "import os; os.chdir(...)"`, and even `dangerouslyDisableSandbox` all still fail. Core fact: the shell's kernel cwd is a DELETED directory the OS won't resolve, and zsh `cd` updates `$PWD` without a real `chdir()`, so no subprocess

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

wan-huiyan

wan-huiyan/agent-traffic-control

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Shell pinned to a deleted worktree cwd blocks all git/subprocess work

Problem

Mid-session, a git worktree that your Bash shell is running inside gets removed — you squash-merged

deleted its branch, ran git worktree remove, or (most insidiously) the Claude Code harness auto-cleaned the worktree after the branch merged. From that point, every Bash command's git or python invocation fails:

fatal: Unable to read current working directory: Operation not permitted

or, from Python:

PermissionError: [Errno 1] Operation not permitted

The shell's kernel working directory is now a deleted directory the OS (macOS especially) refuses to resolve via getcwd(). Every subprocess inherits that broken cwd at startup and dies before doing any work.

Context / Trigger Conditions

The error is Unable to read current working directory: Operation not permitted on git, and PermissionError: [Errno 1] Operation not permitted on python — at startup, before any real work.
pwd lies. cd /valid/absolute/path && pwd prints the valid path, but a git/python in the same && chain still fails. This is the diagnostic fingerprint: zsh's cd updated its internal $PWD variable (so the builtin pwd reports the new path) but did not perform a successful chdir() syscall — it getcwd()'d the dead dir first (for $OLDPWD tracking) and aborted the real chdir. So child processes still inherit the dead kernel cwd.
The harness prints "Shell cwd was reset to /…/.claude/worktrees/" after each Bash call — it re-pins every fresh shell to the dead path.
Common origin in Claude Code: you were working in .claude/worktrees/<x>, the PR merged, the branch was deleted, and the worktree got pruned — pulling the rug out from under your own shell.

Solution

You cannot recover git/subprocess use from this shell. Stop trying — these all FAIL (verified):

cd /valid && git … — cd updates $PWD only, no real chdir.
git -C /repo … — git still getcwd()'s its own process cwd at startup, fails.
mkdir -p <the-deleted-path> then cd — recreates the path with a NEW inode; the shell holds a handle to the OLD deleted inode, so getcwd() still fails (pwd then prints .).
python3 -c "import os; os.chdir('/valid'); import subprocess; …" — Python's import machinery getcwd()'s the dead cwd (path-importer cache) and raises PermissionError before/around your chdir.
dangerouslyDisableSandbox: true — it's a kernel cwd problem, not a sandbox-policy problem.

What still works: the Write / Edit tools use absolute paths and do NOT touch the shell cwd. So:

Finish authoring any files (handoff docs, code, notes) with Write/Edit to absolute paths — those persist on disk fine.
Move the git work to a fresh shell. Either:
- Tell the user the exact cd /abs/repo && git … recipe to run in a new terminal (a fresh shell spawns with a valid cwd), or to type it with the ! prefix in Claude Code (that runs in their interactive session, often at a valid cwd), or
- Continue in a new Claude Code session (fresh shell, valid cwd).
Don't lose the work that already committed. Anything committed/merged BEFORE the prune is safe on the remote/main — only post-prune git steps are blocked. Verify the merge landed by reading the remote via the GitHub API (gh also needs cwd, so use the user's terminal or a prior gh pr view result) rather than local git.

Verification

Confirm the fingerprint: cd /valid/abs/path && pwd && git status — pwd prints the valid path, git status errors Operation not permitted. That combination = this trap (not a real repo/perm problem).
After moving to a fresh shell: pwd returns a real absolute path AND git status runs — recovered.

Example

S264d (2026-06-20): built the Explorer redesign in .claude/worktrees/explorer-redesign, squash- merged PR #1265, the branch was deleted, and the harness pruned the worktree. Every subsequent Bash command failed Unable to read current working directory. Tried (all failed): cd primary && git, git -C primary, mkdir -p the dead path + cd, python3 -c "import os; os.chdir(...)", dangerouslyDisableSandbox. The merged code was safe on main (0dd47e77, verified via an earlier gh pr view). Wrote the two handoff docs with the Write tool (absolute paths — worked), and handed the git checkout -b … && git add … && git commit && git push && gh pr create step to the user for a fresh terminal.

Notes

Prevention is cheaper than recovery: do a worktree's remaining git/handoff work BEFORE deleting its branch or letting it be pruned; or run git from the primary repo path, not from inside a throwaway worktree you're about to merge away. The Claude Code harness auto-removes merged/unchanged worktrees, so "merge my PR" can silently delete the ground under your shell.
The misleading part is the pwd-lies symptom — without it you'd assume a permissions/sandbox bug and waste attempts on chmod/sandbox flags. The real cause is a deleted cwd, full stop.
See also: safe-bulk-worktree-branch-cleanup, recover-killed-session-from-transcript-and-worktree (sibling worktree-lifecycle skills; this one is specifically the deleted-cwd-blocks-subprocess trap).

同仓库更多 Skills

同仓库

gh-pr-merge-worktree-checkout-trap

wan-huiyan/agent-traffic-control

Diagnose and bypass `gh pr merge --squash --delete-branch` failing with "failed to run git: fatal: 'main' is already used by worktree at ..." when another git worktree has main checked out. Use when: (1) you run gh pr merge and see this exact error, (2) you have multiple worktrees in the repo (e.g. `.claude/worktrees/*`), (3) the error appears even though the GitHub merge itself looks fine. The merge SUCCEEDED on GitHub — only gh's local-side effect (post-merge `git checkout main`) failed. Verify via `gh pr view N --json state,mergedAt`; if state=MERGED, you're done. This also applies to `gh pr checkout` and any other `gh` subcommand that tries to touch the local main branch while another worktree has it claimed. v1.2.0 (2026-05-26) adds the sequential-error variant: if you re-run from the main-repo worktree after the first error, you can then hit "cannot delete branch <feature-branch> used by worktree at <feature-worktree>" — same one-checkout-per-branch invariant, this time applied to the feature branch. Cl

2026-07-102

cjk-structured-llm-output-truncates-json-needs-2x-tokens

wan-huiyan/agent-traffic-control

When generating LONG Chinese/Japanese/Korean (CJK) STRUCTURED output (a big JSON report, a multi-section document) from an LLM chat API, the response truncates mid-JSON and your parser throws "no parseable JSON" / "Expecting ',' delimiter" / JSONDecodeError — even though the SAME prompt in English worked. Root cause: CJK is token-heavy (≈1–2 tokens per character vs ≈0.25 for English), so a report that fit your max_tokens in English overflows it in Chinese. Some models ALSO hard-cap output well below what you request (e.g. qwen-max caps at 8192) and silently truncate. Use when: a zh/ja/ko structured-generation run fails JSON parsing, worked in English, or a specific model truncates while others on the same prompt succeed. Covers the ~2× token budget rule, per-model output caps, and a salvage that recovers the complete sections from a truncated object.

2026-07-082

design-subagent-with-plan-schema-executes-and-deploys-live-infra

wan-huiyan/agent-traffic-control

Catch the failure where a subagent dispatched ONLY to DECIDE/DESIGN (a judge, a design-panel synthesizer, a "pick the mechanism" agent) instead EXECUTES the plan — and, having full Bash/gcloud/bq, provisions LIVE infrastructure (creates a BQ dataset/table, a DTS scheduled query, a log metric, a paging alert policy) and even git-commits code — when you only wanted a recommendation. Use when: (1) you author a Workflow/Agent whose structured-output schema has a field that reads as an execution mandate ("this_session_plan", "exact ordered steps", "deploy_steps", "what was provisioned") and the agent has mutate-capable tools; (2) a design/judge agent's result says "DONE — created X" / "provisioned live" instead of "recommend X"; (3) you are about to trust a decision agent's self-report of what it changed. The agent treats a "plan/steps" output field as a TODO to carry out, not a proposal. Fix: constrain design/decision subagents READ-ONLY in the prompt (explicitly: "do NOT run any mutating bq/gcloud/git command; S

2026-07-082

git-add-u-after-async-post-commit-hook

wan-huiyan/agent-traffic-control

Prevent (and recover from) `git add -u` + `git commit --amend` + `git push --force-with-lease` catastrophically rolling thousands of unrelated tracked-file deletions into an amended commit when the project has an async post-commit hook that mutates tracked files (e.g. regenerates `docs/site/*.html`, `docs/site/index.html`, `MEMORY.md`, or any other tracked artefact in a background `&` / `nohup` / "running … in background" process). Use when: (1) you just made a small commit, the post-commit log line says `[post-commit] … running … in background`, and you're about to amend with corrected message / typo / issue ref; (2) `git commit --amend` output reports `1000+ files changed, … insertions, NNN,NNN deletions(-)` when you only intended a 6-file change; (3) the force-pushed branch on origin shows a massive deletion diff and `git status` after the amend shows previously-tracked files like `MEMORY.md`, `.github/`, `.cursor/`, `scripts/` as Untracked; (4) you ran `git add -u` reflexively before `--amend` on a projec

2026-07-082

main-bash-cwd-persists-nested-worktree

wan-huiyan/agent-traffic-control

Prevent and diagnose nested git worktrees created at the wrong filesystem path when orchestrating parallel work from the main Claude Code agent. Use when (1) you ran `git worktree add .claude/worktrees/<name> ...` from the main agent's Bash tool, (2) `git worktree list` shows the new worktree at an unexpected nested path like `.claude/worktrees/<previous-worktree>/.claude/worktrees/<name>` instead of the intended top-level location, (3) a subagent dispatched to the intended path reports "worktree path mismatch" or operates from a longer nested path. Root cause: the main agent's Bash tool **persists cwd between calls** (per its docstring: "The working directory persists between commands"). An earlier `cd /abs/path && cmd` changes the main shell's cwd; a later `git worktree add <relative-path> ...` resolves against that persisted cwd rather than the project root, silently creating nested layouts. This is the **inverse** of the subagent variant (subagent-bash-cd-wrong-worktree) — subagent shells reset per call,

2026-07-082

merged-pr-not-deployed-gate-label-missing

wan-huiyan/agent-traffic-control

Diagnose "I merged my PR + CI is green but the live service still doesn't show my changes." Use when: (1) a code-bearing PR has been squash-merged into main with all required status checks passing, (2) the user reports the change is still missing from the deployed environment minutes-to-hours later, (3) the repo has a `pull_request: types: [closed]` workflow gated on a label (typically `auto-deploy`, `deploy`, `ship-it`) and/or a path filter, (4) the deploy workflow's run row in `gh run list` shows `conclusion=skipped` for your PR's branch — visually identical to `success` in the run summary. Distinct from `gha-auto-deploy-never-ran-skipped-mask` (sister skill: same "skipped masks failure" symptom class but different cause — that skill is about the FIRST time the gate fires and the deploy step then hits a permission gap; THIS skill is about the routine case where the gate correctly works and the PR simply didn't satisfy it). Trigger phrases: "I can't see the changes live", "merged but not deployed", "PR shipp

2026-07-082

name	shell-pinned-to-deleted-worktree-cwd-blocks-git
description	Diagnoses + recovers the "every shell command now fails `fatal: Unable to read current working directory: Operation not permitted`" trap, which appears AFTER a git worktree you were running commands in gets removed/pruned mid-session (you merged + deleted its branch, ran `git worktree remove`, or the Claude Code harness auto-cleaned a merged/unchanged worktree). Use when: (1) git AND python both error `Operation not permitted` / `PermissionError: [Errno 1] Operation not permitted` on startup; (2) `cd /valid/abs/path && pwd` PRINTS the valid path but the very next `git`/`python` in the SAME command still fails (pwd lies); (3) the harness prints "Shell cwd was reset to <some-.claude/worktrees/...>" after each Bash call; (4) `git -C /repo`, recreating the dir with `mkdir`, `python3 -c "import os; os.chdir(...)"`, and even `dangerouslyDisableSandbox` all still fail. Core fact: the shell's kernel cwd is a DELETED directory the OS won't resolve, and zsh `cd` updates `$PWD` without a real `chdir()`, so no subprocess can escape it. The Write/Edit tools still work (absolute paths, no cwd) — so you can finish authoring files; only git/subprocess work is blocked, and must move to a fresh shell. Prevention: don't delete/auto-clean the worktree you're shell-active in until its git work is done.
disable-model-invocation	true
author	Claude Code
version	1.0.0
date	"2026-06-22T00:00:00.000Z"
last_verified	"2026-06-22T00:00:00.000Z"

Shell pinned to a deleted worktree cwd blocks all git/subprocess work

Problem

Mid-session, a git worktree that your Bash shell is running inside gets removed — you squash-merged

deleted its branch, ran git worktree remove, or (most insidiously) the Claude Code harness auto-cleaned the worktree after the branch merged. From that point, every Bash command's git or python invocation fails:

fatal: Unable to read current working directory: Operation not permitted

or, from Python:

PermissionError: [Errno 1] Operation not permitted

Context / Trigger Conditions

The error is Unable to read current working directory: Operation not permitted on git, and PermissionError: [Errno 1] Operation not permitted on python — at startup, before any real work.
pwd lies. cd /valid/absolute/path && pwd prints the valid path, but a git/python in the same && chain still fails. This is the diagnostic fingerprint: zsh's cd updated its internal $PWD variable (so the builtin pwd reports the new path) but did not perform a successful chdir() syscall — it getcwd()'d the dead dir first (for $OLDPWD tracking) and aborted the real chdir. So child processes still inherit the dead kernel cwd.
The harness prints "Shell cwd was reset to /…/.claude/worktrees/" after each Bash call — it re-pins every fresh shell to the dead path.
Common origin in Claude Code: you were working in .claude/worktrees/<x>, the PR merged, the branch was deleted, and the worktree got pruned — pulling the rug out from under your own shell.

Solution

You cannot recover git/subprocess use from this shell. Stop trying — these all FAIL (verified):

cd /valid && git … — cd updates $PWD only, no real chdir.
git -C /repo … — git still getcwd()'s its own process cwd at startup, fails.
mkdir -p <the-deleted-path> then cd — recreates the path with a NEW inode; the shell holds a handle to the OLD deleted inode, so getcwd() still fails (pwd then prints .).
python3 -c "import os; os.chdir('/valid'); import subprocess; …" — Python's import machinery getcwd()'s the dead cwd (path-importer cache) and raises PermissionError before/around your chdir.
dangerouslyDisableSandbox: true — it's a kernel cwd problem, not a sandbox-policy problem.

What still works: the Write / Edit tools use absolute paths and do NOT touch the shell cwd. So:

Finish authoring any files (handoff docs, code, notes) with Write/Edit to absolute paths — those persist on disk fine.
Move the git work to a fresh shell. Either:
- Tell the user the exact cd /abs/repo && git … recipe to run in a new terminal (a fresh shell spawns with a valid cwd), or to type it with the ! prefix in Claude Code (that runs in their interactive session, often at a valid cwd), or
- Continue in a new Claude Code session (fresh shell, valid cwd).
Don't lose the work that already committed. Anything committed/merged BEFORE the prune is safe on the remote/main — only post-prune git steps are blocked. Verify the merge landed by reading the remote via the GitHub API (gh also needs cwd, so use the user's terminal or a prior gh pr view result) rather than local git.

Verification

Confirm the fingerprint: cd /valid/abs/path && pwd && git status — pwd prints the valid path, git status errors Operation not permitted. That combination = this trap (not a real repo/perm problem).
After moving to a fresh shell: pwd returns a real absolute path AND git status runs — recovered.

Example

Notes

Prevention is cheaper than recovery: do a worktree's remaining git/handoff work BEFORE deleting its branch or letting it be pruned; or run git from the primary repo path, not from inside a throwaway worktree you're about to merge away. The Claude Code harness auto-removes merged/unchanged worktrees, so "merge my PR" can silently delete the ground under your shell.
The misleading part is the pwd-lies symptom — without it you'd assume a permissions/sandbox bug and waste attempts on chmod/sandbox flags. The real cause is a deleted cwd, full stop.
See also: safe-bulk-worktree-branch-cleanup, recover-killed-session-from-transcript-and-worktree (sibling worktree-lifecycle skills; this one is specifically the deleted-cwd-blocks-subprocess trap).