upvote
We will write about it. The best way to think about it is that codemode solves a different problem than bash in that bash is a way for the agent to run a particular tool: running bash.

Codemode is a way for the LLM to orchestrate harness level tools. The reason this happening now, is because the models by the labs are increasingly trained on this. Codex for instance in responses lite requires codemode to even perform parallel tool calling.

reply
Codemode is a fancy name some MCP authors coined for the practice of providing scripting/method chaining for their MCP tools. It's generally implemented by providing some kind of code execution tool, the LLM calls it with a script, and the MCP server runs it in a sandbox.

It's pretty effective because of the reasons you noted, but there's a composability problem since each MCP has its own sandbox and can't call into the other ones.

IIUC Pi offer a workaround for this, the harness runs the sandbox and populate it with the MCP tools, that way the composability problem is solved and every MCP do not have to implement their own sandbox.

reply
My understanding is that code mode is supposed to be implemented by the harness, not the MCP provider. You chain multiple MCP providers as well as other harness provided tools inside the sandbox.
reply
My timeline might be wrong (I remember a cloudflare article mentionning the "in MCP" case), but anyway yes there's tools to do it in the harness now and it's the better idea.
reply
yes codemode is when you want to utilize this ability AND you want MCP tool calls as part of your scripts

codemode lets you execute scripts in a runtime where your MCP tools are made available as function calls

this matters for cases where the MCP tool is the only way to do something and you do not have an equivalent CLI, API, whatever to script with

reply
From my understanding, code mode came about due to some agents not having access to a shell.
reply
The value is that rather than an agent chaining together tool calls itself (which means each step sends the result back to the agent for it to analyse and work out what to do next), it writes a script for the harness to execute that chains together all the calls. The major benefits are:

* speed - much fewer hops back to the LLM

* fewer tokens - intermediate execution steps in the script don't leak into context, only the final result does.

* repeatability - if the LLM needs to repeat work, it can reuse a script it wrote last time.

If you have a harness that has access to a full shell and knows how to use bash or python, you'll often see it writing little scripts. For setups that don't (ie normal model API requests with tool calls), you can give it an lightweight secure execution environment like just-bash, or quickjs.

reply
But agents do write scripts, in bash. And they are very good at it. And bash is quite efficient with its pipeing.
reply
And I said that they do this in my last paragraph. But you need an execution environment for this, and you don’t get this automatically when just interacting with models via their API
reply
this seems to be an incomprehensible point for these people to understand. its really quite bizarre
reply
Bash scripts don't really help when you're dealing with MCP tools or other tools that are local to the harness itself.
reply
Agents just do this anyway, how is it a “mode”? I always see the agent writing scripts in a tmp dir to execute or even just inlining bash and python scripts.
reply
Perhaps the appeal is a stronger and more customizable lockdown on agent capabilities.
reply
We're in a HN submission about the least locked down LLM harness, it's too late for that.
reply
We're in an HN submission about the least locked down by default harness. Pi is aimed at being extended, openclaw is a good example of this. You can buy a box of razor blades and put them in any number of razors.
reply
Right the benefit of pi's customization is that it is exactly as locked down or not as you want it to be, in exactly the way you want it to be, and you can inspect it to verify.
reply
but these bash scripts can not execute MCP tools.

What if I have an MCP Tool LookupZip(City) and want to chain it with a bash tool that prodcues a list of 100 cities. And then I want to filter again to the largest Zip code.

reply
Yeah but arguably that tool should be a cli anyway, or could easily be converted to one. The benefit of MCP is that it's _less_ capable than bash.
reply
Not in my testing. A lot of the benefit comes from the tool definitions (from mcp) existing in the context window of the first turn. You could replicate this of course by describing your cli tool in the initial user/system prompt- but, mcp is already 'built' for this at the client (harness) level generally.
reply
These bash scripts certainly can curl the mcp server which is exposing the tool, however.
reply
thanks! it now clicked for me. so instead of cat its read_file, even if read_file resolves to cat, cat is not always available.
reply
Rather, instead of shell_tool(command: "cat ...")
reply