[rtibblesbot]

Summary

• --remote --detach starts the run (or finds it live) and exits 0 without attaching; a non-TTY start used to exit 64 either way.
• python chef.py remote status prints the run's state, start time, exit code, Studio link and log paths.
• remote status exits 0 finished ok, 3 running, 4 finished failed, 5 no run.
• A detached chef's stdin is /dev/null, so a token or Studio-version prompt fails the run instead of blocking; --detach --prompt is refused.

References

Closes #880.

Reviewer guidance

Suggested review: Full code review.

• Confirm that refusing --detach --prompt at parse time, and having a detached chef exit 1 with an EOFError traceback (in the session log only) at its first input(), is the fail-fast you asked for.
• Decide whether a start with no terminal and no --detach should also get /dev/null stdin; as on upstream, it blocks at a prompt until someone reattaches.
• CI has run only f85a68b; after pushing, check that test_detached_chef_fails_at_input_instead_of_blocking and test_attached_chef_reads_typed_input pass, since the agent's sandbox denies the pty they need under real tmux.

1. With a profile in ~/.config/ricecooker/remote.toml, run python chef.py --remote --detach < /dev/null from a chef dir — it exits 0 and the chef runs on the box.
2. Re-run the same command while the chef runs — it exits 0 and prints that the run is already running.
3. Run python chef.py remote status while the chef runs — it prints the start time and exits 3.
4. Re-run remote status after a run that uploaded a channel finishes — it prints the DONE: Channel created at link and both log paths, and exits 0.
5. Run --remote --detach with no Studio token on the laptop or the box — remote status reports it finished failed (exit 4).

Open risk:

• A chef that calls getpass reads the tmux pane, not stdin, so a detached run still blocks there until attached.

AI usage

Used Claude Code to plan, implement and test the change against a local box. Verified with the remote test suite, prek, and CI on a fork.

---

Written by rtibblesbot, an LLM-based coding agent.

🟡 Waiting for feedback Last updated: 2026-10-28 02:46 UTC

[rtibbles]

Should fail fast at input rather than blocking.

[rtibblesbot]

Done in 5d5f357a: a --detach run gives the box chef stdin from /dev/null, so its first input() raises EOFError. remote status then reports the run failed (exit 4) instead of running forever.

• I searched ricecooker/ for input(. There are 2 call sites and 3 prompts: the token prompt (utils/tokens.py:52), plus Studio's version prompt and --prompt, which both go through prompt_yes_or_no (commands.py:228). The one stdin redirect covers all three, so no per-site change was needed.
• A plain --remote run still gets the tmux pane as stdin, so its prompts can still be answered after you attach.
• test_detached_chef_fails_at_input_instead_of_blocking: CI with real tmux on fork PR rtibblesbot/ricecooker#28. Without the fix it times out at 30 s; with the fix it passes.
• docs/remote.md: the --detach bullet now says that a prompt fails the run.

[rtibblesbot]

The fix is now d7a1944b (replaces 5d5f357a): --detach --prompt is refused at parse time rather than failing the run after upload.