Skip to content

os-dev cleanup prescribes git worktree remove --force, which disables the one guard protecting a parallel agent's uncommitted work #7055

Description

@os-project-manager

Filed unassigned and unlabeled for triage, out of scope for #6902 / PR #7046 (that card only touches .claude/skills/pm-dispatch/SKILL.md; this lives in .claude/agents/os-dev.md). Noticed while cross-reading the two files for contradictions.

What the file says

.claude/agents/os-dev.md:150, resource rule 4:

Clean up when done: after the PR is up, remove your worktree (git worktree remove <path> --force) — leftover node_modules trees exhaust the container's disk, which fails as confusingly as OOM.

Why --force is there, and why it is still the wrong instruction

--force is not gratuitous. A worktree that has run pnpm install carries an untracked node_modules/, and plain git worktree remove refuses on modified-or-untracked content. So the flag was almost certainly added to make the documented cleanup actually work.

The cost is that it suppresses the refusal for every reason, not just the harmless one. That refusal is the only thing standing between a mistyped or stale path and another agent's live work — in a container where several agents hold worktrees side by side (four were present while this was written), and where the branch's own unpushed commits are also protected by it. A dev on the 2026-08-08/09 shift used the prescribed command and tripped the safety warning; the current wording gives it no way to tell "this is just node_modules" from "this has work in it".

Same shape as the repo's own git stash rule: the danger is not the command, it is that the isolation a dev believes it has does not extend to the thing being clobbered.

Suggested direction (not a decision — the fix shape is the maintainer's or triage's call)

Remove the ignored bulk first, then let the guard do its job:

rm -rf <path>/node_modules && git worktree remove <path>   # no --force

Then a refusal means what it should mean: something in there is not committed, so stop and look. If the unforced form still refuses for reasons nobody wants to hand-diagnose, the wording should at least say to re-read git status in that worktree before reaching for --force, rather than prescribing the flag unconditionally.

Two adjacent readings worth checking at the same time, since they share the file and the assumption:

  • .claude/skills/dogfood-verification/SKILL.md:124 carries the same flag, but there it is qualified ("if the local branch isn't locked") and the tree it removes is a throwaway under /tmp — plausibly fine as-is, and named here only so a sweep does not silently change it too.
  • The cleanup step is worth stating as a step of the task rather than a trailing suggestion; a dev whose session dies after the PR is up never reaches it, which is how the disk fills in the first place.

Not a blocker for anything in flight

No open PR touches .claude/agents/os-dev.md at filing time. Impact is bounded by how often a dev types the command against a path that has real content — rare, but silent and unrecoverable when it happens, which is why it is filed rather than left as a note.


Generated by Claude Code

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions