Write/Edit tools silently succeed (file never persisted) on Windows when target path contains square brackets — dispatched agent context

Summary

During a long-running dispatched agent (background, isolated worktree, Windows-native Claude Code), Write and Edit tool calls reported success but files were never written to disk. The agent identified the failure mode as paths containing square brackets (Next.js dynamic route convention like [[...slug]]/) and worked around it via Bash heredocs + Node scripts. The dispatched PR ultimately shipped correct content thanks to the workaround, but the dispatch was 2-3× slower than usual (~83 min vs the typical 30-60 min for comparable dispatches in the same project).

The silent-failure aspect is the most dangerous part: tool calls returned success, so the agent only discovered the issue after verifying with git status post-write.

Smoking gun

The dispatched agent self-documented the workaround in a one-shot helper script (found in the project tree post-merge):

/**
 * <Phase identifier> dispatch helper — writes the catch-all page.tsx into
 * the [[...slug]]/ directory. Used once because the agent harness Write
 * tool has trouble with bracketed paths.
 *
 * Run with: node web/scripts/write-catchall.mjs
 * Then delete this file before commit (it's a one-shot).
 */

The agent identified bracketed paths as the failure mode and worked around it by invoking Node directly to perform the write.

Environment

• Platform: Windows 11 Pro 10.0.26200
• Shell: Git Bash (MINGW64) + PowerShell 7+
• Project type: Next.js 16 application (uses bracketed dynamic route directory names like [slug]/, [[...slug]]/)
• Dispatched agent context: Agent tool, isolation: "worktree", run_in_background: true
• Failing path examples (Next.js convention):
• <worktree>/web/src/app/[[...slug]]/page.tsx
• <worktree>/web/src/app/[...slug]/page.tsx
• Same Write tool worked fine in the main session (foreground, no worktree isolation) — including writing 400+-line files at non-bracketed paths

Reproduction hypothesis (not independently verified)

1. Dispatch a background agent via the Agent tool with isolation: "worktree" on Windows
2. Have the agent call Write with a file_path containing [ or ] (e.g., a Next.js catch-all route at <worktree>/src/app/[[...slug]]/page.tsx)
3. Tool returns success; file is not created on disk
4. Subsequent Edit calls against any path (bracketed or not) appear to fail similarly, suggesting either a path-specific failure that cascades to session-wide degradation, or an Edit-specific issue distinct from Write

What worked (the workaround)

The agent successfully wrote bracketed-path files via Bash heredoc:

cat > "/path/with/[brackets]/file.tsx" <<'EOF'
<file content>
EOF

And via Node directly:

import fs from 'node:fs';
import path from 'node:path';
fs.writeFileSync(path.resolve(__dirname, '../src/app/[[...slug]]/page.tsx'), content);

This suggests the issue is in the harness's Write/Edit tool path-resolution layer specifically, not in Node's or bash's bracket handling.

Severity

Medium. A workaround exists (heredoc / Node script). But:

• Silent failure is the worst kind of failure — Write returning success when the file wasn't written is genuinely dangerous
• The agent discovered the issue only by checking git status after each write; agents that don't think to verify will ship broken work and not know
• Next.js dynamic routes use square brackets pervasively; any project that uses Next.js App Router will hit this when adding new routes via a dispatched agent

Secondary observation: worktree isolation appears to leak

During post-merge cleanup, the orchestrator found that the dispatched agent's files (11 new files + 10 modified files matching the merged PR content) ALSO appeared in the main checkout, not just the agent's isolated worktree. The leaked files were content-identical to what origin/main received via the merged PR, suggesting the agent's workaround (heredoc / Node) was using absolute paths that resolved against the main checkout rather than the worktree.

This is a secondary symptom — the primary issue is the Write/Edit silent failure that forced the workaround in the first place — but it suggests the harness's path-resolution layer for dispatched agents may have a deeper issue with how it grounds relative-vs-absolute paths in worktree contexts.

Open questions

1. Is the failure 100% bracketed-path-specific, or does it cascade to non-bracketed paths once triggered? (The agent gave up on the Write tool entirely after the first failure rather than testing path-by-path, so this isn't determinable from the existing transcript.)
2. Does Edit fail the same way for bracketed paths, or does Edit have a separate failure mode? (The agent used Python replace() for edits, but the trigger isn't documented as bracket-specific for edits.)
3. Is there any way the harness can detect the silent-failure mode and emit a real error? Even a noisy false-positive would be safer than silent success.
4. Does this affect foreground (main-session) Claude Code on Windows the same way, or only dispatched-agent worktrees?

Repro environment notes

• This wasn't deterministic enough for me to capture a single-line repro before the dispatch finished. The next time I observe a phase that needs bracketed-path file creation in a dispatched agent context, I'll capture a tighter repro and follow up here.
• Workaround is being documented in our project's local guidance so future dispatched agents skip the diagnostic step and go straight to heredoc/Node for bracketed paths.

Happy to provide more detail or attach transcripts if helpful — let me know what would be most useful.