[MODEL]

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Other unexpected behavior

What You Asked Claude to Do

/team-lead implementa la spec AI_plans/etp-4086-consolidar-cobertura-enterticketv2-api.md. Lanza subagentes con Sonnet 5 que se encarguen de los WI paralelizables, tal y como habíamos establecido en la spec

(Translation: "/team-lead implement the spec at AI_plans/etp-4086-consolidar-cobertura-enterticketv2-api.md. Launch Sonnet 5 subagents to handle the parallelizable work items, as established in the spec.")

What Claude Actually Did

1. Launched 3 parallel principal-engineer subagents, each running git worktree add off a shared git submodule branch (enterticket-admin, a submodule of a superproject, with its git-dir redirected to .git/modules/enterticket-admin/).
2. All 3 subagents independently hit a core.worktree misconfiguration in the shared, non-worktree-scoped git config — each self-diagnosed and self-"fixed" it redundantly via git config --worktree core.worktree <path>.
3. Shortly after, the shared file .git/modules/enterticket-admin/config became corrupted — replaced by a directory containing a single empty fragments/ subfolder — breaking git status/add/commit entirely for the main checkout (fatal: unknown error occurred while reading the configuration files). A backup directory found on disk shows the exact same corruption pattern occurred once before, 3 days earlier, unrelated to any agent activity.
4. A follow-up background task (spawned via the "suggested background task" chip feature, without an explicit isolated worktree) committed a production bugfix directly onto the shared integration branch instead of the intended per-work-item branch, requiring manual git-history surgery to move it afterward.
5. Multiple subsequent subagent attempts to repair .git/modules/enterticket-admin/config (write the corrected file) were blocked by an auto-mode permission classifier under "Modify Shared Resources" — including a subagent's attempt to simply revert its own prior mv, which was also blocked — forcing the human user to apply the fix manually via their own terminal.
6. A later subagent run performing git-history cleanup (moving a commit between branches, restoring pre-commit file state) returned flagged with a "SECURITY WARNING: Irreversible Local Destruction" classifier tag, requiring manual human verification of the subagent's actual file changes before trusting the result.

Expected Behavior

1. Creating multiple git worktree add checkouts in parallel against the same submodule's shared git-dir should not corrupt shared git metadata (config becoming a directory is not standard git behavior under any known git error path).
2. A "suggested background task" spawned without an explicit working-directory/worktree argument should not silently operate on the same branch/checkout as the parent session — it should default to an isolated context, or clearly warn the user/agent that it will not be isolated.
3. When an auto-mode permission classifier blocks a write (e.g., "Modify Shared Resources"), it should also block the reverse/undo of an already-applied change by the same actor in the same task, rather than allowing a partial, half-applied state (rename-away-without-restore) to persist silently until a human notices.
4. Security classifier tags ("Irreversible Local Destruction", "Modify Shared Resources") fired on legitimate, correctly-scoped repair actions (verified after the fact to be accurate and non-destructive) without enough detail to distinguish a real risk from a false positive — this made a already-costly recovery process (a multi-hour, multi-agent detour) harder to trust and verify.

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Haven't tried to reproduce

Steps to Reproduce

_No response_

Claude Model

Sonnet

Relevant Conversation

Session covers: initial parallel work-item dispatch → Jira sub-task branch-naming correction → discovery of .git/modules/enterticket-admin/config corruption reported independently by 3 subagents → phased diagnosis/backup/repair requiring the human to manually apply a config-file write and a cleanup rm -rf after two separate "Modify Shared Resources" blocks → discovery of a stray commit on the wrong branch caused by an un-isolated spawned background task → a reconciliation subagent run flagged "Irreversible Local Destruction".

Impact

High - Significant unwanted changes

Claude Code Version

Claude Desktop 2.2553.1

Platform

Anthropic API

Additional Context

1. The exact corruption signature (config file replaced by a directory containing one empty fragments/ subfolder) had already occurred once, 3 days prior to this session, per a pre-existing backup directory found in the git-dir — suggesting a reproducible, environment-level bug (possibly related to concurrent git config writes, a submodule + git worktree add interaction, or interference from another git GUI tool with background maintenance active on the same repo — GitKraken metadata was found in the git-dir) rather than something solely caused by this session's parallel agents.
2. Repo structure: git submodule (enterticket-admin inside a superproject) combined with multiple git worktree add checkouts for parallel agent work — this specific combination (submodule + worktrees + parallel writers) is the likely trigger surface.
3. Platform: macOS (Darwin 27.0.0), Claude Desktop 2.2553.1, Claude Code / Claude Agent SDK session running the /team-lead custom command with principal-engineer subagents on Sonnet 5.