Workers can pick up stale pi binary when bash -lc PATH differs from interactive shell

[tmustier]

Problem

Symphony spawns Pi workers via bash -lc "exec env ... pi --mode rpc ...". When the user has multiple Pi installations and bash -lc resolves a different PATH order than their interactive shell, the worker can pick up a stale Pi binary that's missing newer models.

Reproduction

If the user has:

• /usr/local/bin/pi → version 0.52.12 (old, no gpt-5.4)
• ~/.local/bin/pi → version 0.65.2 (current, has gpt-5.4)

And their bash login profile puts /usr/local/bin before ~/.local/bin in PATH:

# Interactive shell (works)
which pi    → ~/.local/bin/pi (0.65.2)

# bash -lc (breaks)  
bash -lc 'which pi'    → /usr/local/bin/pi (0.52.12)

Symphony's worker then fails with: Model not found: openai-codex/gpt-5.4

This error is classified as permanent_error / model_not_found, so the issue is never retried — it permanently blocks.

Root cause in code

rpc_client.ex:build_command/1 uses the bare pi.command setting (default: "pi") in the bash -lc invocation. There's no version check or path validation.

Suggested fixes

1. Documentation (easy)

• WORKFLOW.md template: add a comment recommending pi.command: /full/path/to/pi when multiple installations exist
• Skill doc / preflight: add a check that bash -lc 'which pi && pi --version' matches the expected version

2. Preflight check (medium)

Add a preflight step that runs bash -lc 'which <pi.command> && <pi.command> --version' and compares with the interactive shell's pi --version. Warn if they differ.

3. Resolve path at startup (better)

When pi.command is a bare name (no /), resolve it to an absolute path at orchestrator startup using the current shell's PATH (not bash -lc), then use the absolute path in the worker command.

Environment

• Pi version (interactive): 0.65.2
• Pi version (bash -lc): 0.52.12
• Symphony orchestrator: built from source
• OS: macOS