

Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Can someone please tell me how to disable it permanently in pi? I have already disabled it in settings.json, but, it just doesn't get disabled:
and{ "source": "npm:pi-mcp-adapter", "extensions": [ "-index.ts", "-builtin:codemode" ] }"autoEnableCodemode": false,by freakynit - This seems to come down to object model and tooling differences between sandboxed JavaScript and sandboxed Unix. You can make Unix commands do whatever you like, including special commands to send things back to the coding agent. But the output of a Unix command is arbitrary text (by default) and the AI will have to pipe things into some other command when there’s a lot of output. In the coding harness I use, I see OpenAI’s LLMs writing a lot of pipelines, often processing the output with python. Also the whole thing needs to run in a VM.
A JavaScript sandbox works somewhat differently since the output is an object. Tools are functions that naturally return objects. Composing functions and async calls work differently. If a function returns a very large object, the coding harness could be smarter about presenting the result to the LLM. Maybe JacaScript works better than bash for calling mcp APIs?
But you can have both! The LLM can get direct access to a JavaScript sandbox, which in turn provides an API to access a Linux sandbox. This seems to be what pi is doing with code mode?
by skybrian - I've been using Codemode with the new Dot so that Dot can coordinate my agents with:
1. Launching workflows, so it avoids some large configuration
2. Reviewing work, with reviewers restricted to read-only tools or specific tools. Or some tools for reviewers to check hashes, correctness, etc.
3. I'm using the widely used pi-extensible-workflows. So say you want to stop a workflow, you gonna call workflow_stop. Or check the status with workflow_status. Without Codemode, Pi exposes an API, that the agent can use. So yes, you can call workflow_status. Or call workflow_stop. With Codemode, the agent can do something more complex like a for loop over all the list of workflow ids and get a status and stop them all (again, it's just an example).
So basically, Codemode allows to build a sort of framework for more correctness like using a typed language vs. JavaScript without a linter. It gives boundaries essentially. And also Codemode allows an agent to do things more easily like using internal Pi extensions.
- The headline is "What is codemode". As someone who did not know what codemode is, I had to read until the section "Orchestrating The Harness", where it says "If you are not familiar with Codemode, it’s basically just a way to issue tool calls from within some language, in our case JavaScript."
I could then somehow get what is meant from the examples, but the contents of the article do not at all match the headline.
by planb - Sadly this seems like introducing a very complex apparatus for little gain. I don't need MCP or many tool calls that the agent can program around - in fact the promise of pi was that you basically just need bash and no other tools. The minimally-invasive approach would have been to just "inject" tool calls as virtual bash commands. No code mode required, no hands vs. brains dichotomy. LLM can use language of its own choosing to interact with tools.by dnlgrmm
- I'm not sure why almost all codemode implementations choose Javascript. I prototyped an agent[1] to use bash as the language for codemode, which in my opinion worked equally well and requires no teaching (there is literally 0 prompt to teach the LLM about codemode. A tool named "bash" is enough to have them know the usage).by ylxdzsw
- If you're like me and you're still wondering what "codemode" is after reading the article and comments:
It's giving the harness a small js sandbox to compose tool calls and manipulate the data they return before reading it into context.
- Between this and the Cloudflare post, this is a lot of words and no simple system level picture. Here's what I think is going on:
1. Homoiconicity: Harness mechanics are kludgy and we need proper homoiconicity to uniformly handle code (tool calls) and data ("natural language") as token streams.
2. Actor semantics: for isolation, encapsulation and concurrency.
3. Object capabilities: injected references and no ambient authority. Capabality-based reflection/introspection is a clean way to discover interfaces and affordances.
"Code mode" or whatever is basically rediscovering this by hacking outward from LLM token streams, instead of from system design principles based on decades of computer science. It is the beginning of treating an LLM as a programming-language runtime participant (any takers for eval/apply?) rather than as a text/token generator with the harness as an ad-hoc interpreter.
If existing implementations of code mode don't already support all this, I anticipate they will keep piling on hacks till they get to this point.
----
I think it was Dan Ingalls who said "An operating system is a collection of things that don't fit into a language. There shouldn't be one.". I see the same for harnesses -- they're awkward middle children which fit neither in an LLM nor in the programming environment.
Maybe the answer is to partner LLMs with Common Lisp or Scheme fibers / Spritely Goblins or Erlang BEAM and be done!
by ssivark