Run any Skill in Manus with one click

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

Stars2

Forks0

UpdatedJuly 8, 2026 at 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

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

wan-huiyan

wan-huiyan/agent-traffic-control

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

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

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).

More from this repository

same repository

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).