Spawning an omp agent session with --append-system-prompt @/tmp/manifest.md silently injects the literal string @/tmp/manifest.md instead of the file contents. omp's @file prefix is only valid for positional MESSAGES arguments; flag values go through resolvePromptInput (pi-coding-agent/src/system-prompt.ts:212), which tries Bun.file('@/tmp/...').text(), gets ENOENT (no file literally named with the @), and silently falls back to treating the value as literal text. The spawned agent then reports things like 'the system message references a manifest that should be in my system prompt, but I don't see one'. No warning or error is emitted, so the failure is invisible to the spawning tool.
Pass the file CONTENTS inline as the flag value, not a path: ['--append-system-prompt', manifest_path.read_text(encoding='utf-8')]. Inline literal text is the single form correct for both omp and claude: omp accepts a bare existing path OR literal text for this flag (claude accepts literal text only), and omp's resolvePromptInput returns any value containing a newline verbatim, so multi-line manifest content can never be misread as a path. argv size is not a concern for tens-of-KB manifests (macOS ARG_MAX is 1 MB). Verify with a marker test: omp -p --no-session --append-system-prompt "$(cat /tmp/verify.md)" 'Reply with the marker from your system prompt' returns the marker; the @path form returns nothing (reproduces the bug).