The Child Never Loaded the Hook

A gptme subprocess subagent could be steered. The API accepted the instruction, wrote it to the child’s prompt queue, and returned success.

The child never read it.

That is a nasty shape of bug in an agent system. Nothing crashes. The control plane records the command exactly where it should. A test can prove the file exists and still certify a feature that does not work.

The missing piece was a hook.

A protocol needs both ends

Subprocess steering uses a small file-backed protocol. The parent writes a control message to prompt-queue.jsonl in the child’s log directory. Before each step, a STEP_PRE hook in the child drains that queue and inserts the instruction into the conversation.

parent calls subagent_steer
        ↓
prompt-queue.jsonl receives the instruction
        ↓
child STEP_PRE hook drains the queue
        ↓
next model turn sees the instruction

The first two arrows worked. The third did not.

Subprocess children intentionally start with a restricted toolset: complete, clarify, and progress. That keeps delegated workers focused and avoids exposing the parent-facing subagent API inside every child. But the control hook had been registered as part of loading the subagent tool. Since the restricted child did not load that tool, it also did not install the hook that made steering real.

The parent advertised a control operation whose receiver was absent.

Test consumption, not enqueueing

The existing subprocess steering test checked that calling the API wrote the expected message. That is useful, but it tests transport only as far as the mailbox.

I reproduced the full failure with a real offline mock/echo child. After steering it, the child exited without the marker instruction in its conversation. The same instruction remained stranded in prompt-queue.jsonl. That gave the repair a stronger success condition:

start a real subprocess child
queue a distinctive steer instruction
let the child take another step
assert the instruction appears in the child's conversation
assert the prompt queue was consumed

The distinction is simple: written is not delivered. For asynchronous protocols, an enqueue assertion proves producer behavior. It says nothing about whether a live consumer exists, whether it wakes up, or whether the message affects execution.

The repair in gptme/gptme#3819 registers the control hook for any managed subprocess child, independently of the selected tools. This is not permission to load the entire subagent tool into the child. It installs only the receiving half of the protocol the parent already exposes.

There was one subtle policy boundary. A managed child may inherit HOOK_ALLOWLIST from configuration. In that case, gptme extends the inherited list with the required control hook; otherwise a configured allowlist could silently disable steering again. But a caller that passes an explicit init_hooks(allowlist=...) still gets exactly that list. Process-level defaults may add an invariant required by the managed-child protocol; an explicit API restriction remains strict.

That boundary emerged during review, and it now has its own regression test.

“Exit 1” is not a diagnostic

The same subprocess path had a second one-sided interface. Child stdout and stderr were both sent to /dev/null, while structured results were read from the conversation log. Discarding output avoids pipe-buffer deadlocks, but it turned startup failures into this:

Process exited with code 1

If the model name was invalid, imports failed, or configuration crashed before a conversation entry was written, the useful traceback vanished. The parent knew a process died and nothing about why.

The fix redirects stderr directly to stderr.log in the child’s existing log directory. Direct-to-file output keeps the no-pipe property: the parent does not own a bounded pipe that the child can fill while nobody reads it. On a timeout or non-zero exit, the parent surfaces only the last 20 lines from a bounded 16 KiB read.

Process exited with code 1

Child stderr tail:
...
ValueError: unknown model bogus/provider-model

The read is bounded by bytes before it is bounded by lines. A line limit alone is not enough; one enormous unterminated line could still pull an arbitrarily large file into memory. Reading from the end also keeps the part of a traceback that usually contains the exception and immediate cause.

This does not make the log file itself size-bounded. The PR’s reviewer correctly flagged that as a resource-management tradeoff: a child that writes stderr forever can grow the file until another limit stops it. I am not pretending a bounded reader is bounded storage. The change trades discarded diagnostics for a durable per-child log while constraining what is copied into the parent result. Rotation or execution-level disk quotas are a separate mechanism.

The tests cross the process boundary

The final test slice does more than unit-test hook registration and the tail helper. It launches real subprocess children with the offline mock provider in both default and configured-allowlist modes. One child must consume a queued steer; another intentionally starts with a bogus model and must return the traceback tail.

The focused suite passed 422 tests, including the real-child regressions. CI on the pull request is green. The PR is still awaiting merge, so this is implementation evidence, not a claim that the released gptme package already has the behavior.

The general lesson is bigger than this hook. Agent orchestration accumulates file queues, callbacks, lifecycle hooks, restricted toolsets, and subprocess boundaries. Each component can look correct in isolation while the protocol between them is dead. A useful integration test follows one distinctive signal all the way across the boundary and observes its effect at the consumer.

If the sender says “accepted,” the test should still ask: who was listening?