vercel-py

A process's stdout and stderr readers share one log stream, and whichever reader needs data pumps the next record off it and routes it into the right buffer. Pumping was serialized by a plain lock, and a reader only checked its own buffer before queuing for that lock. So if the stderr reader was mid-pump when a stdout line arrived, the line landed in the stdout buffer, but the stdout reader, already waiting on the lock, then took its turn pumping and blocked on the stream for a record that would never come, because the server was waiting for the client to act on the line it had just sent. That is exactly the shape of a stdio MCP session that forwards the server's stderr: the first reply arrives and the second request is never sent. This replaces the lock with a condition. Only one reader pumps at a time, and it reads from the stream without holding the condition; every other reader waits on the condition and rechecks its buffer each time a record is routed, so data routed on its behalf is returned straight away. Buffer reads and writes now also happen under the condition, which matters for the sync reader across threads. The async and sync readers keep sharing the same core, backed by and respectively. A "skip the pump if someone else pumped while I waited" counter fixes the async case, but not the sync one: isn't fair, so the pumping thread re-acquires the lock and blocks on the stream while the other thread's line sits in its buffer. The new sync regression test fails with that approach. Two behaviours are kept on purpose: cancelling the reader that is pumping still breaks the stream for both readers, since the underlying line iterator can't be resumed, and closing the last reader still waits for an in-flight pump to finish before closing the response. The async condition shields its acquire; that's safe because it is never held across a stream read. 🤖 Generated with Claude Code

TypeScript 3.8.0 added an hook to so callers learn a command's ID as soon as it starts, without switching to detached mode and paying for extra round trips. This adds the Python counterpart as , a scoped, -style handle. It takes the same arguments as and makes the same single streaming request. Entering the block reads only the start record, so the handle's ID is available right away while the process keeps running. Leaving the block normally waits for exit and applies . Leaving it through an exception closes the stream without waiting for, or killing, the process. On , only the step that opens the stream takes part in lifecycle recovery, so nothing raised inside the block can cause the command to run a second time. now uses the same stream-reading code, and its behaviour is unchanged. We considered teaching to be both awaitable and a context manager, but it doesn't fit the sync API. Sync runs eagerly and returns a , so by the time a statement could enter it the process would already have exited. Making it lazy would break every existing . In async, returning an operation object instead of a coroutine would also break callers that use or . A separately named method behaves the same way in both APIs and leaves alone. One thing to watch for: async and sync drive output differently, following the split interactive sessions already use. The async handle pumps output to its destinations from a task group while the block runs. The sync handle starts no threads. Output is read only while you iterate the handle or call , and anything unread stays in the connection rather than in an SDK buffer, the same as readers. Callers who want output drained continuously can hand to their own thread. 🤖 Generated with Claude Code

Sandbox commands can now take standard input, so the Python SDK no longer raises for it. Rather than copying the TypeScript / methods, this follows : starts the command with and exposes a writer on , writes and closes it, and feeds a command it waits on. In the async API is an , so it works with , task groups, and anything else that sends to an AnyIO stream under asyncio or Trio. In the sync API it is a writable that can be wrapped in . Processes from and always have a writer, matching the TypeScript SDK, where any from can write to stdin. That lets you write to a process started by someone else. Together these cover the stdio MCP server case: one task sends JSON-RPC lines while another reads responses from . Writes go to the new stdin endpoint as base64, in 512 KiB requests, serialized behind a FIFO lock so concurrent sends arrive in call order. Every request carries the offset the service has confirmed so far. That makes network errors, 429, 502, and 503 safe to resend with the same body, and 504 timeouts are resent for as long as the process keeps reading. After the process exits or stops reading, writes raise ( in sync code), and / ignore that the way a shell ignores a closed pipe. Any other failure raises the new . If that failure may have delivered part of a write, the stream refuses further writes but can still be closed. Things reviewers may want to look at: The first stdin call on a process sends an empty request to read the confirmed offset, as the TypeScript SDK does. Following vercel/sandbox#381 there is no fallback for sandboxes without offsets. If that response has no , the write fails before sending anything rather than assuming offset 0. A 504 that doesn't report bytes written counts as stalled, and no extra request is made to find out. writes the input from inside the NDJSON loop, right after the initial metadata record arrives, and does not read output meanwhile. That keeps one code path for sync and async and relies on the service buffering output. If writing fails the command is killed, and the error is a rather than a raw , so sandbox lifecycle recovery can never re-run a command that has already started. A looked-up handle learns the confirmed offset from that first empty request, so its writes continue after whatever other handles wrote. Two handles writing at the same time will lose input, though. Each handle sends its own idea of the offset, and the service drops bytes it thinks it already has. The TypeScript SDK has the same limitation and documents it the same way. The service returns both for a process that was never started with stdin and for one that stopped reading. For handles this SDK started, that can only mean "stopped reading", so it is treated as a closed pipe. For a looked-up handle, a first request that comes back unavailable raises ("not started with stdin=subprocess.PIPE, or stopped reading"). That way can't silently drop input sent to a process without stdin. Once one request has succeeded, a later unavailable error means "stopped reading" again. A distinct error code from the service would let this be exact. on a looked-up process only closes stdin if it was given input or the handle has been written to. Otherwise, fetching a running stdio server just to read its output would send it end-of-file. Processes created with always close, as in . handles take the same and options. The run-as-user launcher already passes the original stdin through to the command, so nothing changes in the wrapper scripts. construction now defaults to no writer, and each lookup path asks for one explicitly. That way a user process created without doesn't pick up a looked-up-style writer. Garbage collection does not close the sync stream, since closing takes a network request. The public Python docs still say stdin is unsupported. They need a follow-up once this ships. 🤖 Generated with Claude Code