plan: write tool rejects new files inside the plan directory #49168

Summary

In plan mode, the write tool refuses to create a new plan file inside the
designated plan directory, reporting "Cannot use write to modify files outside
the Plan directory" for a path that is inside that directory. Writing the
identical content to the identical path via the shell tool succeeds, so this is
a false positive in the plan-mode write guard, not a filesystem issue.

Environment

• opencode version: 2.0.3
• OS: Darwin 25.6.0 (macOS arm64)
• Terminal: ghostty (TERM=xterm-ghostty, COLORTERM=truecolor); also reproduced from zed integrated terminal
• Shell: /bin/zsh
• Install/channel: latest (npm global @opencode/cli)
• Active plugins: none found in config

Reproduction

1. Enter plan mode. The system instruction states plan files must be written
   only in /Users/<user>/.opencode/plan.
2. Ask the agent to save a new plan file, e.g. write to
   /Users/<user>/.opencode/plan/005-example-plan.md.
3. The tool errors. Then write the identical content to the identical path via
   cat > <same path> << 'EOF' in the shell tool — it succeeds immediately.

Expected Behavior

write succeeds: the target path is inside the directory the guard itself
names as the allowed plan directory.

Actual Behavior

The write tool errors (twice in a row, identically):

{"error":{"type":"tool.execution","message":"Cannot use write to modify
files outside the Plan directory: /Users/<user>/.opencode/plan"}}

Additional Context

• The refused path is unambiguously inside the directory named in the error.
• /Users/<user>/.opencode is a plain directory (no symlink); file permissions
  are normal (shell write to the same path succeeds instantly).
• The guard string outside the Plan directory is present in the CLI bundle
  (bin/opencode.exe), so this is the built-in plan-mode write guard.
• Hypothesis: the guard compares against a different resolved path than the one
  it announces (e.g. a session-managed plan file path), or it only permits
  overwriting existing files and rejects creation of new files.
• Reproducible consistently (two consecutive attempts failed identically; shell
  fallback worked both times).