Comment by wren6991
5 days ago
> And while we could have just wired up the metadata to enable better MCP extensions, we also think that MCP with Codemode solves quite a few of the issues that it traditionally had.
There's just something that bothers me about this. Normally if LLMs want to compose multiple operations, they have the perfect tool for this: bash, or whatever other OS shell is available. It's why I was always confused by Codemode-type constructs for direct chaining of tool calls; see also the way highly-RL'd modern models will fall back to sed or python for complex file edits.
It seems like Codemode is raised here as the perfect tool for chaining or composing MCPs, but isn't that backwards? LLMs are already given the perfect tool for that, and the problem is that MCPs aren't exposed to that tool.
I happen to think codemode is useful, but not the full answer. I have a long and skewed history with chaining things in MCP and built a dozen or so enterprise ones (see https://taoofmac.com/space/blog/2026/04/29/2341 for notes) and it all falls back into the trade-off between agent scope/context and tool coverage: If you are using a coding agent it will have no trouble sorting out any tool regardless of how many are exposed (it's just a matter of either progressive tool disclosure or good tool metadata, since the coding agent will just go at it and expend whatever tokens are needed), whereas in a "normal", limited, scoped agent that has only a few things it needs to do (like handling a ticketing system) codemode is pretty much overkill.
Pi is primarily a coding agent, so yeah, code mode makes sense, but I've found that better MCP design saves everyone a lot of trouble and would also probably have improved the thing's reputation overall (I personally am not fond of the line protocol, would rather have protobuf and more typing, but it is what it is).
Addendum: My unfettered notes on chaining MCP operations are here: https://github.com/rcarmo/umcp/blob/main/docs/CHAINING.md
> Normally if LLMs want to compose multiple operations, they have the perfect tool for this: bash, or whatever other OS shell is available.
I many scenarios, e.g. running the harness server-side, as is the case for chat interfaces, you don't really want to expose OS shell access as that opens up a huge security attack surface.
> I many scenarios, e.g. running the harness server-side, as is the case for chat interfaces, you don't really want to expose OS shell access as that opens up a huge security attack surface.
It does, but a restricted user account mitigates the large majority of those issues. A sandbox mitigates even more.
The number of remaining exploits left is probably going to be the same as the number in the harness. More, in fact, as many of them have no human review anyway.
You can give the LLM a bash without giving it the full /usr/bin.
That's been a trivially solved problem for decades.
That has been one of the most common exploits for decades.
3 replies →
Cloud products based orchestrations with proper security mechanisms configured, don't have shell access and should only communicate over proper network mechanisms.
Rootless immutable containers without shell access, or SaaS products from multiple vendors with WebAPIs as the only touch point.
Yeah, I'm probably over-indexing on local use cases due to my own preferences, prejudices, biases etc. For a coding agent like Pi it does seem reasonable to expect some kind of shell access though, unless some people are using it as a CLI chat client with MCP?
the trouble is that bash inherits the ambient authority of the shell. most of times, if you run MCP in a cli the agent will have access to the key for example (unless your agent do something exotic)
writing python or JavaScript for tool calls make it possible to have an actual permission system (rather than the one usually employed that consists in a regex matching the cli - trivially defeated if the agent has access to an interpreter for instance)
[flagged]
Uh, you just figured out their motivation and you somehow came to the opposite conclusion?
Bash is an interface to operate Linux computers. It's not a web interface at all. It's the worst interface for the web.
Code mode is just them running JavaScript for web based APIs. They are using the web native programming language for web tasks. It's actually completely logical once that is clear.
Bash for the web is a terrible idea.
Right, because MCP != web. In fact most of my exposure to MCP has been local tools. Also, for context, we're talking about a coding agent harness that runs on a local machine, and Codemode applies to all of its tools, not just MCP.