# `Snodo.Client.Stdio`
[🔗](https://github.com/joshrotenberg/snodo/blob/v0.4.1/lib/snodo/client/stdio.ex#L1)

Stdio transport for `Snodo.Client.connect({:stdio, command, args}, opts)`.

A process owns a `Port` running `command`. It writes one JSON-RPC message per
line to the server's stdin and reads newline-delimited messages from its
stdout. The server's stderr is not captured. Responses are correlated by ID,
so any number of processes can share one client and have requests in flight
at once.

Options:

  * `:env` - extra environment variables, as `{name, value}` string pairs.
    A `nil` value unsets the variable.
  * `:cd` - the working directory for the command.
  * `:max_line_bytes` - the largest response line to accept, default 16 MiB.
    The rest of a longer line is discarded as it arrives, so the request it
    answered times out; later responses are unaffected.
  * `:on_server_request` - a function of one argument that answers a
    request the server sends to the client, as `Snodo.Client.Transport`
    describes. The connection process runs it in a linked process, one per
    request, and writes the response it returns; a function that raises is
    answered with -32603. `Snodo.Client` always supplies it, whatever the
    negotiated version. A caller that uses this transport directly without
    it gets -32601 for every server-to-client request.
  * `:max_server_requests` - the most server-to-client requests whose
    handlers run at once, default 16. A request over the limit is answered
    with -32603 without running the handler.

The connection process monitors the process that called `connect/2` and
closes when it exits. An exit signal from another process, such as
`Process.exit(pid, :shutdown)`, stops it with that reason. When a request times out, the transport answers the
caller with a -32001 error and sends the server `notifications/cancelled` for
that request ID. When the server exits, or closes its stdin so that a write
to it fails, requests in flight and later requests fail with -32000.
`notify/3` writes a notification and returns once the line is in the port.
When the connection stops, through `close/1` or the owner's exit, handlers
still running for server-to-client requests are killed and their answers
are not sent.

A `notifications/progress` whose token belongs to a request made with
`progress:` is forwarded to the process waiting on that request, which calls
the progress function; with `reset_timeout_on_progress: true` the connection
process also restarts the request's timer. Other server notifications are
dropped. If the progress function raises, the request is cancelled on the
server.

A `subscriptions/listen` request opened with `Snodo.Client.listen/3` shares
the connection with ordinary requests. The connection process correlates
the acknowledgement, the events, and the terminal response by the
subscription ID (the request ID, carried in each notification's
`_meta["io.modelcontextprotocol/subscriptionId"]`), delivers the events to
the owner (see `Snodo.Client.Subscription`), and monitors the owner. Closing
the subscription, or the owner's exit, sends `notifications/cancelled` for
the request. When the server exits or closes its stdin, or `close/1` stops
the connection, open subscriptions end with a -32000 error.

`close/1` closes the server's stdin. An MCP stdio server exits at EOF after
finishing admitted requests; this transport does not signal or kill it.

# `child_spec`

Returns a specification to start this module under a supervisor.

See `Supervisor`.

---

*Consult [api-reference.md](api-reference.md) for complete listing*