`write_stdin` hallucinated `session_id` loop: model retries unknown IDs (1…N) until guardrail halt

[lfaoro]

Version / branch / commit

zero dev (75a78e7) main

OS and environment

linux / tmux / go 1.26.4

Steps to reproduce

1. Start a run where the model is pushed to implement a multi-file change (plan → implement).

2. Observe (or force) tool calls of the form:

   {"name": "write_stdin", "arguments": {"session_id": 1, "chars": "..."}}

   without a preceding live exec_command session.

3. Confirm:

   • Error: Unknown exec session_id 1.
   • Subsequent calls with 2, 3, … continue failing.
   • Same-error stop may be delayed until the numeric ID stabilizes.

Unit-level coverage already exists for unknown IDs (internal/tools/exec_command_test.go). What’s missing is:

• guardrail signature stability across changing IDs, and/or
• stronger model-facing error text / tests that the stop fires within a small bound when only the id digits change.

Expected behavior

1. write_stdin is only used with a session_id previously returned by a still-running exec_command.
2. Real exec session IDs start at 1000 (not 1).
3. On unknown/missing sessions, the model should stop and choose a different approach (e.g. start exec_command, or use write_file / edit_file / apply_patch for file edits) rather than invent sequential IDs.
4. The repeated-failure guardrail should stop this thrash early even when the numeric ID changes each attempt.

Actual behavior

Example pattern:

I have enough context; expanding the sketch into a full implementation plan.
• Sent input
Error: Unknown exec session_id 1.
• Sent input
Error: Unknown exec session_id 2.
• Sent input
Error: Unknown exec session_id 3.
…
• Sent input
Error: Unknown exec session_id 7.

Later: retries continue (reported up to ~id 150, then restart / halt), ending with the 6× same-error stop on write_stdin.

Relevant logs, screenshots, or error messages

• Wastes turns/tokens and user time.
• Masks real blockers (e.g. missing write tools, permission mode, plan-only constraints).
• User-visible failure mode looks like broken patch/write tooling.
• Guardrail eventually stops the run, but often only after many useless tool calls.