pub fn write_startup_instructions_respecting_existing(
base_path: &Path,
filename: &str,
content: &str,
) -> Result<()>Expand description
Write a NON-CLAUDE.md startup-instructions file (AGENTS.md,
GEMINI.md, QWEN.md, .pi/APPEND_SYSTEM.md, …) WITHOUT ever
overwriting a pre-existing, non-AgentMux-authored file at that path.
codex P1, PR #2788: before
docs/specs/SPEC_PROVIDER_AWARE_STARTUP_INSTRUCTIONS_2026_08_24.md,
every provider’s agent got CLAUDE.md written regardless of provider —
wrong, but harmless to a real Codex/Gemini/etc. project, since AgentMux
was never writing to the filename that project’s own real AGENTS.md/
GEMINI.md actually lived at. Once build_config_files started
resolving the CORRECT native filename per provider, an unconditional
write (the plain std::fs::write every other config file still uses)
would silently destroy a pre-existing, user-authored project file the
moment its name collided with the now-correctly-resolved target — a
real, novel data-loss regression introduced BY fixing the filename,
not present before.
Mirrors write_claude_md_respecting_ownership’s OWNED-vs-foreign
marker check (freely regenerate if AgentMux wrote it, either freshly or
on a prior launch; never touch it otherwise) — WITHOUT that function’s
@import-line side-file fallback offer for the foreign case. That
fuller mechanism is deliberately Claude-Code-@import-syntax-specific;
whether AGENTS.md/GEMINI.md/QWEN.md/pi’s APPEND_SYSTEM.md
support an equivalent include directive their own harness actually
honors is unverified per-provider research this spec didn’t do (§5/§6
of the spec above). The tradeoff accepted here: if the target file is
foreign, this agent’s Soul/AgentMD/Bundle content is simply not
delivered via a file for this launch (logged, not silently dropped) —
a real capability gap, but strictly safer than overwriting a stranger’s
file. Revisit once each provider’s own include syntax is confirmed.