feat: Add a "Code Mode" tool to Rig

[FayCarsons]

• I have looked for existing issues (including closed) about this

Feature Request

The Rig team has been discussing adding a JavaScript execution tool. This would enable a model to write JavaScript, with a custom API exposing functionality on the Rust side, instead of standard structured JSON tool calling.

Motivation

In our own experiments, we've found supplying tools via an embedded JavaScript runtime (Boa, specifically) to be highly effective, with agents able to focus more clearly, use fewer tokens, and keep the context concise. We think there should be a general, though opinionated, way to do this in Rig.

Proposal

The current architecture is expected to look like:

• You define a Rust API, either a module for stateless APIs, or a type (which becomes this in JS) for stateful
• We provide a macro which transforms this into boilerplate that exposes this API in a Boa.js JavaScript engine
• The model responds with structured outputs such as { code : string, description : string }
• The code field is passed to the runtime
• Code executes and the output is made available to your harness

Some questions remain:

• Tools integration: Is this built into our existing tool system, or just driven by structured outputs?
• Async: Is it worth the complexity? Or are users okay with blocking in their API
• Ease of use vs customization: Which is the priority, or can we manage both?
• Safety: Boa has no network or filesystem access by default, do we provide opt-in escape hatches? And how do we surface the risks to users who enable them?

We would love input on the architecture or open questions above, as well as any use-cases we may not have considered.

[linear]

RIG-1212

[Sytten]

For what it is worth, I help maintain rquickjs and we have already rebuilt a lot of the node modules for AWS LLRT (think fs, child_process, net, fetch, etc). Might be a better option of an engine. We have async support too and I can help if you have questions.

[FayCarsons]

@Sytten Totally, I had initially planned this all around Boa because I have a pretty clear idea what the macros generating the Rust->JS bindings would look like, but we're certainly not married to that particular runtime. What are the ergonomics like wrt binding a bunch of functions or a class + methods? Do you think it can be automated?

[Sytten]

It should be fairly easy, it is the core of the plugin system of Caido and we do bunch of fancy things. Like in LLRT we have stream + crypto implementation in pure Rust compared to most engine that implement it in JS. Only extending js class from rust is kinda hard.

You can dynamically load module based on permission so it should be possible to scope.
And we are open to contributions if you want further restrictions like file access per folder.

We are a couple of businesses contributing to it and using it now.

[appcypher]

I don't think rig's code-mode should be in favor of any particular language.

I could make a case for bash. It's readily available on Unix systems, a slimmer runtime, and there's just-bash.

To be fair, our needs are probably different from what you're planning here, so I'd like to learn more about how it works. In our case, we implemented a CLI that lets our agents interact with any MCP server via a CLI and it uses bash to generate the tool calls and other intermediate processing code.

A couple clarifying questions around your intended design:

1. Is your system still about calling MCPs or arbitrary APIs?
2. The bigger benefit of code-mode comes from composing multiple tool calls based on their input and output schema and any intermediate transformations that need to happen in between, in a single code run. For example, take the output of one tool, process it, and pass it on into the arguments of another. How will this system enable that?
3. Can it be language agnostic?

[0xMochan]

+1 for language agnostic, I had some prototyping of what monty integration would look like locally. Ideas of being able to hijack .tool calls to instead register in the runtime directly instead of as formal tools. Perhaps with some way to inject in the preamble.

[dxvid-pts]

Language agnostic does not make sense. Idea of code mode as described by cloudflare is that tool definitions (input/output) are given to the agent as ts structs in e.g system prompt and agent writes typescript code.

So if we previously had my_tool, we now have a my_tool() fn callable in agent generated TS script that under the hood calls the my_tool rust tool. That way the agent can call multiple tools in a batch in one tool call (execute tool)

quickjs only adds <1MB to final binary vs a e.g python runtime would add 100s of MBs I think? Other, more static languages are not even feasable for this.

Bash as proposed is different for every operating system. What if I want to deploy my rig agent on Windows or WASM?

Typescript/JS are under the top 5 languages used and agents are trained heavily on it.

[0xMochan]

https://github.com/pydantic/monty

Monty is much smaller. i also think making it hard coded for JS is restrictive, esp as the space for specialized lanugage runtimes grows. you could even do starlark, lua, etc.

there's other benefits, monty lets you also have type annotations which can be statically checked before execution and even leveraged for dynamic type stuff (sorta like with dataclasses, etc).

[richinex]

If code mode is a synonym for RLM support, and there has to be a choice of runtime Monty might be the best option like others have said.

[FayCarsons]

I think that keeping the architecture modular so that we may add other runtimes in the future is certainly a priority, but a language agnostic code-mode (which, I am using that loosely, not sure it aligns with Cloudflare's concept) is probably not in scope for some time. While a lot of the behavior could be encoded via a Runtime trait, it would complicate things like programmatically generating API documentation which is shown to the agent.

@appcypher to answer your question, this is more focused on exposing arbitrary APIs to the model. More general than MCPs and yes, composition is a huge bonus.