spawn silently fails when invoked through `launch-agent.sh` wrapper from cron context (env-i shortcut path passes)

[442991]

Severity: High (blocks scheduled-restart cron pipeline, which is our primary agent-self-healing mechanism).

Title: spawn silently fails when invoked through launch-agent.sh wrapper from cron context (env-i shortcut path passes)

Repro (the failure path):

1. macOS crontab entry: 30 4 * * * /path/to/scripts/scheduled-restart.sh bookworm
2. scheduled-restart.sh calls launch-agent.sh bookworm --kill --initial-handoff
3. launch-agent.sh issues hcom 1 claude --headless --pty to spawn the agent
4. Spawn fails with Error: Failed to setup Claude hooks. Run: hcom hooks add claude. Agent comes up missing hooks binding.

Reproducer log excerpt (sanitized, from our scheduled-restart.log — Sunday 2026-04-26 04:30:01 BST, Bookworm restart fire):

[04:30:01] [bookworm] SNAPSHOT: saved to /path/to/dispatch-bridge/bookworm/pre-restart-20260426-043001.md
[04:30:01] [bookworm] RESTART: invoking launch-agent.sh bookworm --kill --initial-handoff /path/to/dispatch-bridge/bookworm/pre-restart-20260426-043001.md
Handoff file verified: /path/to/dispatch-bridge/bookworm/pre-restart-20260426-043001.md
Killed tmux session: bookworm
Launching 'bookworm' via hcom with MCP config from /path/to/agents/bookworm/.mcp.json...
Working directory: /path/to/agents/bookworm
Error: Failed to setup Claude hooks. Run: hcom hooks add claude

Note: log shows the same Error: Failed to setup Claude hooks mode also occurred on 2026-04-23 (under v0.7.11 — the original reason for our v0.7.13 upgrade) and 2026-04-25 04:30 + 05:00 + 05:30 BST (immediately post-upgrade, all three agents). Pattern is reliably reproducible from our cron pipeline; we have not yet narrowed which step is the trigger.

Repro (the SHORTCUT that PASSES, do NOT use as canary):

• env -i HOME=/Users/jane USER=jane LOGNAME=jane SHELL=/bin/sh PATH=/usr/bin:/bin:/opt/homebrew/bin /opt/homebrew/bin/hcom 1 claude --tag X --headless --pty
• This was canary 7b in our v0.7.11→v0.7.13 upgrade plan (post-upgrade-hcom-0713-20260425.md, line 43-48). It PASSED. We treated it as evidence the cron-context path was fixed by v0.7.13 PRs Fix headless PTY background launches on macOS #26-28. It was not.

Why the shortcut doesn't reproduce: the real pipeline goes through launch-agent.sh which does additional setup (kills tmux session, recreates, sets TMUX_BIN, runs hcom kill, then spawns). Direct env-i + direct hcom invocation skips all of that. Some interaction between launch-agent.sh and v0.7.13 inside the cron environment is the actual failure vector. We have not isolated which step. Two variables are in play (cron context vs shell context, AND launch-agent.sh wrapper vs bare hcom); we cannot attribute either alone as causal from current evidence.

Possible interaction with Issue #2: if v0.7.13's tightened state-check (Issue #2's mechanism) requires settings.json content to match an expected hash, and launch-agent.sh performs settings.json operations during spawn that diverge from what v0.7.13 expects, that could be the underlying cause. Speculative — flagging for the maintainer's awareness, not strong-claiming.

Expected: spawn completes, settings.json hooks installed, agent comes up with hooks, pty bindings.

Actual (cron-context): spawn appears to start but hook installation fails. Agent registers without hooks binding. Settings.json may be partially written.

Versions:

• v0.7.11: same class of failure (this is what triggered the v0.7.13 upgrade in the first place; we attributed it to PRs Fix headless PTY background launches on macOS #26-28's macOS PTY-spawn fix)
• v0.7.13: still failing in real pipeline despite passing the env-i shortcut canary

Workaround in place: scheduled-restart crons are EMERGENCY-DISABLED (# 30 4 * * * ... and # 0 5/30 5 * * * ... in crontab). Manual relaunch via bash launch-agent.sh <agent> --kill works fine — the failure is cron-context-specific.

Logs/evidence pointers (local files, not for upload):

• /Volumes/Jane-Data/claudeclaw/logs/scheduled-restart.log — Sunday 04:30 BST entry showing the actual failure mode for Bookworm
• /Volumes/Jane-Data/claudeclaw/dispatch-bridge/guardian/post-upgrade-hcom-0713-20260425.md — the canary plan that called this path "fixed"; lines 43-48 are the shortcut that misled us

Ask of hcom team:

1. Is there a known difference in v0.7.13 between cron-context spawn and shell-context spawn re: hook installation?
2. Suggested debugging: minimal repro outside our infra would require reproducing the launch-agent.sh wrapper (or just confirming whether hcom 1 claude --headless --pty --kill --initial-handoff from cron differs from the env-i path).

[aannoo]

couldn't replicate. do you have more info?

---

AI:
Probably a downstream symptom of #32 — the launcher pre-check on 0.7.13
ran the same strict timeout-equality verifier that hcom hooks status
did, so any fix-timeouts.sh rewrite would have flipped pre-check to
false on every cron fire. Setup then re-runs and writes 86400 back;
its post-write self-verify trips the same strict check if anything
(e.g. a concurrent fix-timeouts.sh race) has touched the file
between the rename and the verify. Both paths are the same invariant.

That said, "post-write self-verify failed" alone doesn't explain why
your real cron path bails when the env-i shortcut passes. Plausible
non-timeout candidates that the bool-only return on 0.7.13 masked:

• macOS TCC / Full Disk Access blocking atomic_write to the resolved
  path under cron's launchd context (your shell has FDA, cron likely
  doesn't, especially when the path resolves through a symlink to
  /Volumes/Jane-Data/...)
• get_claude_settings_path() resolving differently in cron vs. shell
  (HCOM_DIR / CLAUDE_CONFIG_DIR / cwd divergence — your
  launch-agent.sh wrapper may set or unset one of these)
• A genuine concurrent rewriter racing the post-write verify

0.7.14 ships two changes that should make this answerable on first
retry:

1. The pre-check uses the canonical verifier as in v0.7.13 hcom hooks status reads claude: not installed after any sed-edit to settings.json, even when hooks are functionally installed #32. Numeric
   timeout-only edits no longer trip it. Setup's post-write verify is
   the same tier — only structurally broken installs fail. Most
   timeout-only races are eliminated as a cause.
2. try_setup_*_hooks returns a structured error and the launcher
   bail now includes: which sub-step failed (atomic_write IO error
   with errno, or post-write verify naming the offending field), the
   resolved settings.json path, HCOM_DIR, CLAUDE_CONFIG_DIR,
   and cwd at invocation. Same diagnostic block surfaces in
   hcom hooks add output. That covers all three candidates above.

Please re-run your cron pipeline on 0.7.14 and paste the new error if
it still bails. Keeping this issue open — #32 is fully explained, but
this one's actual mechanism remains unproven until we see your
post-0.7.14 diagnostic output.

Side note unrelated to the fix, but operationally relevant: if
the deadlock you originally attributed to a 24h Stop-hook timeout
was the Stop hook's hcom poll waiting 24h, the configurable knob
is hcom config timeout <secs> (or env HCOM_TIMEOUT). That controls
the inner poll wait — the actual thing that holds the hook open. The
86400 your fix-timeouts.sh rewrites is the outer Claude Code
hook-killer ceiling, which doesn't trip in normal operation; it's
only a backstop. If you set HCOM_TIMEOUT=10 (or hcom config timeout 10) the inner poll exits cleanly and the outer ceiling
becomes irrelevant — no sed defense needed, and hcom hooks status
stops being a fight.