Only one turn runs at a time

Regardless of whether it was started locally or triggered remotely, only one turn is ever actually running on a given machine at once. A second message sent while a turn is still in progress joins a queue rather than starting a competing loop alongside it.

This is not a throughput limitation so much as a correctness guarantee: it is what makes it impossible for tool calls from two different turns to interleave against the same files or race on the filesystem. Whichever message arrived first runs to completion first, and the other waits.

In practice this feels exactly like two people trying to type into the same terminal at once and taking turns rather than talking over each other, which is the same discipline you would want even if tCode allowed true concurrency here.

This single-worker design is also simpler to reason about from a safety standpoint: there is never a moment where two turns' worth of checkpoints, described in Checkpoints and rewind, could interleave in a way that made /rewind ambiguous about which turn's changes it was undoing.

Sending a message while a turn is in progress is never an error or something that gets rejected; it simply waits its turn in the same queue, and you will see it start processing the moment the one ahead of it finishes.