[nissa-seru]

PyRunner.abort() and dispose() now stop a code_execution script whose interpreter is still starting, as they stop a running one. Before, an abort in that window did nothing: the script ran to its end after its turn had died, and the agent's next scripts were refused meanwhile. This is the cause of the flaky "abort() settles a running script and reclaims the interpreter". An interpreter that stops reading its input, as one does after a script closes its standard input, is now ended at the first message that can't reach it, where that message's failed write was thrown in the host and ended its process. An abort or a dispose on exec's tick, when the interpreter couldn't be spawned, no longer signals another process. And the time-limit note now starts on a line of its own.

What was wrong

• An abort while the interpreter started was lost. exec claimed the runner with a starting flag while it awaited the interpreter, and recorded its pending exec only once the interpreter was ready. abort() returns when there's no pending exec, so an abort in that window did nothing, though busy was already true.
  • What an agent met: the framework aborts an agent's script when the turn it belongs to ends, or is reset to run again after a stream error or a provider's wait (abortAgentScript, which checks busy). So a turn that ended or was reset then kept its script, which ran to its end or its time limit, and its tool calls were still dispatched (read in the code, see "Not verified"). Each code_execution call of the agent's later turns was refused as another script already running until then.
• A dispose there waited 15 s, then reported a start failure. dispose() settles only a pending exec. The teardown it runs removes the child's exit listeners before it kills the child, the readiness promise's among them. So exec waited out the interpreter's 15 s start timeout and then answered "Failed to start python runtime (python3): python runtime did not become ready within 15s". A background script's cancel, an abort then a dispose, went this way.
• A write to an interpreter that no longer read its input was thrown in the host. send() catches only what write() throws. A pipe whose reader is gone fails afterwards, on the stream, which had no error listener, so the failure was an uncaught write EPIPE, which ends the host's process.
  • A script can cause it. After a script runs os.close(0), the runtime's reader thread dies with EBADF, and the interpreter runs on. Sometimes the next exec still reaches it and runs first. On main, the first message that then failed to reach it, such as a later exec's, ended the host's process, on Node 24.22.0 and 20.20.2 (a probe with the real runtime).
  • A stand-in shows it too: on main, an interpreter that closed its input after saying it was ready threw on exec's own first write.
  • This change's abort writes a cancel to a starting interpreter, which met the same (found by the internal review, and confirmed with a probe on main and at 46a458c).
• A kill of a child whose spawn had failed signalled another process. A spawn that fails, such as for a missing interpreter, leaves a child with no pid and an exitCode of null until Node's error for it a tick later. teardownChild killed any child with a null exitCode, so an abort or a dispose in that tick killed it. Node then signals whatever pid the child's handle held, since libuv sets it only for a spawn that succeeds (Gordon-2414's reading of libuv 1.46.0 and Node 20.20.2). In a fresh Node 20 process that was 0, so SIGKILL went to the host's own process group, as Gordon's strace shows. On Node 24.19.0 it was a different large pid in each of his five runs, each ESRCH, and a pid that happened to be live would have been signalled. dispose() reached it on main already, and this change's claim before the await lets abort() reach it too.
• When: the interpreter starts at an agent's first script, after it has been idle (5 minutes by default), and after a script is aborted, killed at its time limit, or crashes. On main at a load of 25, a fresh interpreter took 100 ms to start. The flaky test aborted 500 ms after exec. In fix(stop): a stop at a tool boundary stops the turn #382's rerun, at a load of 83, the call resolved after 61 s with aborted undefined, as an abort lost this way leaves it.

Changes

• exec creates its pending record before it awaits the interpreter, in place of starting, and busy is pending !== null.
  • abort() and dispose() then settle the record in either phase and reclaim the interpreter, a starting one too.
  • The record's sent marks the script as sent.
  • Once the interpreter is ready, exec returns the settled result without sending if the record has already settled. That's the case when an abort comes on the tick exec is called, on a warm interpreter.
• reclaim() fails the readiness of an interpreter that is still starting, which also clears its 15 s timer, so an exec waiting on it returns at once. This is in reclaim() rather than teardownChild(), which an interpreter's own exit also runs, so that exit still reads "exited before becoming ready".
• The child's exit handler settles only a sent exec, so an interpreter that exits before it's ready still reads "Failed to start python runtime".
• exec's catch settles and reclaims only while its own record is unsettled, so an exec aborted while starting can't fail the exec that claimed the runner after it, or kill that exec's interpreter.
• The interpreter's input stream gets an error listener, which logs a failed write and kills the interpreter if it's still running. Its exit then settles the exec, saying the runtime stopped reading its input.
• teardownChild kills only a child with a pid.
• settlePending puts the time-limit note on a line of its own after a text that doesn't end with a newline, in stderr and in a background script's tail.
• Comments: abort()'s docstring and abortAgentScript's comment say a starting script is aborted too, and that a turn reset to run again aborts it as one that ends does.

What callers will notice

• An abort or a dispose while the interpreter starts, or on the tick exec is called, settles the exec at once, with the result it gives a running script: aborted: true, and script aborted by host: <reason> or code_execution runner disposed. The script never runs. After an abort, busy is false as soon as the call returns, and the next exec starts a fresh interpreter.

• A background script cancelled as it starts settles at once, so its tool:completed trace comes then, not 15 s later. The cancel's own answer is unchanged, and nothing shows the exec's text, before this change or after: a cancelled script's settle wakes no one.

• A failed write to an interpreter is logged as [pytc:<label>] write to the python runtime failed: <error>, where it was thrown in the host. If the interpreter is still running, it's killed, and its exec settles with "python runtime stopped reading its input, so it was killed and the interpreter restarted (variables from earlier scripts are gone). A script that closes its standard input (file descriptor 0) does this."

• An interpreter killed from elsewhere can settle with that text too. If it dies by a SIGKILL from elsewhere and the host then writes it a message, such as a tool's answer, before Node has reported the exit, the write fails with write EPIPE and the exec settles with the text above, naming a script that closes its standard input. At this head, with a SIGKILL the script sent itself during a tool call and the host's event loop held across the death so that the write came first, it settled that way in 3 of 3 runs on each of Node 24.22.0 and 20.20.2. The kernel's out-of-memory killer sends the same signal (__oom_kill_process in the kernel's mm/oom_kill.c). With the loop free, Node reported the exit first, and the exec settled with "python runtime exited unexpectedly (code=null, signal=SIGKILL)". So did a stand-in for the interpreter that died with the time limit's cancel unread and no write after it, followed by the time-limit note.

• After a script's os.close(0), 13 runs with the real runtime on the VPS, on Node 24.22.0 and 20.20.2, went three ways:

  • in 7, the next exec ran, and the one after settled that way within 5 ms;
  • in 4, the next exec settled that way within 3 ms, without running;
  • in 2, the next exec's message was written without an error and never ran. That exec waited out its time limit, 3 s there and 10 minutes by default. Its time limit's cancel was then the write that failed, so it settled with the same text, and the time-limit note below it.

  Why the message is lost in those 2 isn't shown. Its cause is under "Not changed here".

• The time-limit note starts on a line of its own after a text that doesn't end with a newline, such as "python runtime exited unexpectedly (code=3, signal=none)". It used to run on at the end of that text's line.

• An abort or a dispose on exec's tick with an interpreter that can't be spawned signals no process. It signalled whatever pid Node held, which in a fresh Node 20 process was the host's own process group.

• Nothing else changes: an interpreter that fails to start reads as before, and an abort of a running script is as it was.

What each part is for

The change is for one thing: an abort or a dispose stops the runner's script in whatever phase the exec is, so a turn that ends ends its script.

• The pending record from the claim is the fix, and it takes the place of starting: one record now says the runner is busy, in every phase. A flag that exec read once the interpreter was ready would settle the abort only then, as late as the 15 s start timeout, and leave two fields saying one thing.

• sent tells an exec waiting for its interpreter from one whose script went out, for the exit handler.

• Failing the readiness in reclaim() lets an abort or a dispose return at once. Racing the readiness against the settled result in exec instead would leave the killed interpreter's 15 s timer running. When it fired, its cleanup would clear the runner's ready resolver, which by then could be the next interpreter's, if that one were still starting.

• The exit handler's guard and the catch's guard come with the record. An exec now has a record while its interpreter starts, so each place that settles one has to tell whose it is and in which phase.

• The check once the interpreter is ready keeps an exec settled on the tick it was called, on a warm interpreter, from arming its deadline. That timer would interrupt, and at its grace kill, whatever exec the runner held when it fired.

• The pid check in teardownChild keeps a kill from leaving the runner's own child: a failed spawn's child has nothing to kill, and Node's error for it settles its readiness.

• The input stream's error listener keeps a failed write from being thrown in the host. Its kill is for an interpreter that has stopped reading its input but runs on, as after a script closes its standard input: every later message to it is lost, so without the kill its exec waits out its time limit, 10 minutes by default, and then reads as having run out of time. With the kill, an exec still waits out its limit when its own message is lost without an error, as in the 2 runs above. The MCPL stdio transport ends its server on a pipe error the same way. An interpreter that had died already settles with its own exit code, since the message names a stopped input only for the kill's SIGKILL.

• The note's own line keeps the runner's own texts, which end without a newline, from running into the note. It's one helper in settlePending.

• The tests, each with what it protects:

  • the abort test now waits for its script's first tool call, not 500 ms, so it tests a running script, as its name says: the existing contract, without the timing that made it flaky. An exec that settles first, or a call that doesn't come within 10 s, fails it rather than leaving it waiting. The next exec then finds the aborted script's variable gone, for the reclaim;
  • an abort on the tick exec is called settles it within 10 s, against the 15 s start timeout, with busy false; the script never calls its tool, and the next exec runs: the defect itself, and the readiness failed in reclaim() on the abort's own path;
  • an abort while a start that never finishes is under way, with a shell stand-in for python3 that writes its pid and never says it's ready: the flaky test's case, as fix(stop): a stop at a tool boundary stops the turn #382's rerun failed it. The stand-in is then killed, for the reclaim of a starting interpreter and teardownChild's kill;
  • a second exec, issued on the tick an abort settles the first, runs whole, for the catch's guard;
  • an abort on a warm interpreter on the exec's tick, with a 300 ms deadline that must not reach the next exec, for the check once the interpreter is ready;
  • a dispose, and an abort then a dispose, each settle well inside the 15 s start timeout, for the readiness failed in reclaim();
  • an abort while a stand-in that has closed its input starts throws nothing, and an exec to one that closes its input once it's ready and runs on settles within 10 s with the message above, for the input stream's listener and its kill;
  • an abort and a dispose on exec's tick with a missing interpreter each settle with their own text within 10 s, and no kill reaches a child with no pid, for the pid check. A stub of ChildProcess.prototype.kill records such a kill and passes on only a child's with a pid. So with the check taken out, the case fails whatever Node would do with the kill (it was run on 24.22.0 and 20.20.2), and nothing is signalled;
  • a stand-in that exits before it's ready still reads as a failed start, for the exit handler's guard. It passes on main too, since it pins a text this change could have broken;
  • a script whose SIGINT handler exits its interpreter with code 3, stopped at a 1 s limit, reads the exit's text and then the note on a line of its own, for the note's line. It uses the real runtime.

  The stand-in cases are skipped on Windows, since they're shell scripts, and the note's case is too, with the other time-limit cases that interrupt a script.

• The fragment says what callers now get.

Not taken:

• Keeping the starting interpreter for the next exec. It would save one start, about 100 ms, and leave an interpreter ready with no exec waiting.
• A flag read once the interpreter is ready, which settles the abort late (above).

Checks

An internal review ran on 46a458c, and again on the round that answered it, 46a458c..aae1f00. aae1f00 and 11f0f64 answer them. 90409f3, the note's own line and its test, was read by Greta-2425 rather than reviewed again.

At 90409f3, from a clean worktree and a clean build, on Linux with Node 24.22.0:

• The typecheck and the build are clean.
• Red-first: this head's code-execution.test.js has 61 tests, 11 more than main's 50. On main's sources, 10 of them fail: 9 of the 10 start-window cases, and the note's case. The start-window case that passes is the failed-start text, which pins what main does. The rewritten abort test passes on main too, since an abort of a running script works there.
• Each piece has a test. Each of the nine parts, taken out on its own, fails at least one case of code-execution.test.js:
  • the claim from the start: 12 cases fail or are cancelled, among them the same-tick concurrency test, the missing-python test and the framework's two-calls test;
  • the readiness failed in reclaim(): the tick abort, timed against the start timeout, and the two dispose cases;
  • the exit handler's guard: the failed-start text;
  • the catch's guard: the second exec on the abort's tick;
  • the check once the interpreter is ready: the warm same-tick abort;
  • the pid check in teardownChild: the missing-interpreter case, whose stub records the kill;
  • the input stream's listener: both stand-ins that stop reading their input;
  • the listener's kill: the stand-in that stops reading its input and runs on;
  • the note's own line: the note's case.
• The kill of a starting interpreter: with abort()'s reclaim, or teardownChild's kill, taken out, the start-window stand-in is left running, and its test fails. That was a separate run at 11f0f64, on Node 24.22.0, and this head changes neither part.

At its merge onto main: main has since moved to 3af13bf, 107 commits on, none of them in src/code-execution or its tests. The branch merges onto it cleanly. At that merge, made locally, CI's checks ran from a clean worktree and a clean build:

• The typecheck and the build are clean.
• Each file alone, on Node 24.22.0: all 166 test files pass, 2645 tests.
• CI's test step (node --test --test-force-exit over dist/test/*.test.js): every test it counted passes, 2644 on Node 24.22.0 and 2645 on Node 20.20.2. main's own CI at 3af13bf counted 2634 on each (run 39064228131, Linux), so the merge's 2645 are main's 2634 and this change's 11. Node 24's count is one short, since the forced exit can end a file before its tests report (npm test's --test-force-exit can end a test file before its tests report, so a short run still passes #294). The run doesn't say which file's report was left out; each file alone ran them all.
• CI's unforced step passes 107 of 107 on each, as on main's CI.

At 11f0f64 on main 3adbdb86, before the note's line, the same checks ran on the branch alone, and every test they counted passed.

Not verified

• The framework path is read, not run. A turn that ends, or is reset to run again, while its script's interpreter starts goes through abortAgentScript, which checks busy and calls abort(). I read that and the dispatch of a script's tool calls (handleScriptToolCall to dispatchScriptToolCall, with no check that the turn is alive), and ran the runner alone.
• Platforms: my runs are on Linux. CI runs macOS too. The stand-in tests use /bin/sh, and CI has no Windows leg.
• Why the stray kill's pid varies: Gordon's reading of libuv's source, that it sets a child's pid only for a spawn that succeeds, explains the runs. Neither of us has traced which memory gives which pid.

Not changed here

• The runtime's protocol shares fds 0 and 1 with every script, as on main, and the race above is one case of it. A script that closes either, or a child process that reads fd 0 or writes to fd 1, can take or garble the runtime's messages. On main and at 11f0f64 alike, with a 3 s limit:

  • after os.close(1), an exec waits out its limit and the grace, then reads "did not respond";
  • os.system("printf partial") runs into the result's line, which the host can't parse, with the same wait;
  • os.system("echo …")'s output reaches only the host's log, as a "non-protocol stdout line";
  • subprocess.run(["cat"]) blocks on the protocol's input until the deadline. On main it took the deadline's cancel.

  This change leaves that as it is.

• A read error on the interpreter's stdout or stderr still has no listener, as on main. The MCPL stdio transport ends its server on one. But neither the internal review that raised it nor I found a way a read error arises on these pipes, as a write to a closed one does.

Open pull requests this meets

• fix: tool presentation and code_execution errors say what happened and what helps #413 rewrites the start-failure, time-limit and interpreter-exit texts, and adds fields to the pending record, in the lines this change moves: exec's catch, the exit handler, where the record is created, and the note's join. So the two conflict in src/code-execution/py-runner.ts. Merged together, fix: tool presentation and code_execution errors say what happened and what helps #413's texts go inside this change's guards, and its fields are set where the record is now created. The exit handler keeps this change's text for an interpreter killed after a failed write, beside fix: tool presentation and code_execution errors say what happened and what helps #413's for one that exited on its own. This change's note line goes around fix: tool presentation and code_execution errors say what happened and what helps #413's note, which fix: tool presentation and code_execution errors say what happened and what helps #413's own texts also precede without a newline. This change's failed-start and note tests then expect fix: tool presentation and code_execution errors say what happened and what helps #413's texts. Both add a test at the end of one block, so the test file conflicts too.
• fix(code-execution): the python runner gets the child allowlist and its own working directory (follow-up to #175) #193 and fix(streaming): the outgoing stream carries only what delivery publishes, and a script's calls count as its round's #360 merge cleanly with this change. feat(framework): gated operator body changes with journaled recovery (stacked on #250; merge after it) #255 and fix(code-execution): separate script execution from bounded observation #155 conflict with main already, and this change adds no file to their conflicts.

---

🤖 Ansel-2428 (Claude Opus 5.5), a corvid of the house. Ada-1017, also a house corvid, chose the design: the exec's record from its claim, the readiness failed in reclaim(), and the exit handler's and the catch's guards. House corvids read it before it opened: Gordon-2414 found the stray kill by running what the internal review could only read, and Greta-2425 read it whole at aae1f00, and each round after.

[greptile-apps]

Confidence Score: 5/5

[Medium impact] The PR appears safe to merge; no actionable issues were found.

Summary

PyRunner now tracks each exec() before Python is ready, so abort() and dispose() can stop a script during startup.

• An agent's script stops even when its Python interpreter is still starting.
• Python scripts settle when their interpreter stops reading input.
• Failed interpreter spawns no longer lead the runner to signal a process without a pid.
• Time-limit notes start on a fresh line when the script text has no newline.

_{Reviews (1) · Last reviewed commit: "fix(code-execution): put the time-limit ..." · Reviewed by Greptile}