fm-spawn: claude crewmate launch hardcodes bare 'claude', failing on multi-account machines

[tkt028]

Summary

bin/fm-spawn.sh's claude launch template runs bare claude, which resolves to the
default config dir (~/.claude). On a machine with multiple Claude accounts — where auth
lives in alternate config dirs and the default ~/.claude is empty/unauthenticated — the
spawned crewmate lands on the "Select login method" wall and can never start.

Details

Launch template (claude branch):

claude) printf '%s' 'CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION=false claude --dangerously-skip-permissions __MODELFLAG____EFFORTFLAG__"$(cat __BRIEF__)"' ;;

There is no way to tell fm-spawn which account/profile a crewmate's claude should use. On a
multi-account setup the machine typically has a per-shell profile mechanism (e.g. an
llm-profile-style lm <profile> + cl flow that exports CLAUDE_CODE_USE_WEB_LOGIN=1, or a
CLAUDE_CONFIG_DIR pointing at an authenticated dir). fm-spawn bypasses all of that.

Impact

FirstMate cannot spawn autonomous claude crewmates on a multi-account machine — a real
cross-machine portability blocker, since each machine has its own auth/profile flow.

Suggested fix

Make the crewmate launch verb machine-configurable rather than hardcoding bare claude:

• Let a local, gitignored config (e.g. a launch-command/prefix knob, or honoring
  CLAUDE_CONFIG_DIR / the machine's profile flow) supply how claude is invoked, while
  fm-spawn keeps appending its own autonomy + brief args
  (--dangerously-skip-permissions, CLAUDE_CODE_ENABLE_PROMPT_SUGGESTION=false,
  "$(cat <brief>)").
• Preserve today's behavior when the knob is absent (bare claude), so single-account
  machines are unaffected.

This keeps the mechanics in fm-spawn.sh while allowing each machine to point crewmates at an
authenticated account.

---

🤖 Claude Code · claude-opus-4-8 · 2026-07-15