In Claude Code Mode’s documented Jira example, full issue records stay inside a JavaScript sandbox. Claude receives only the keys and titles of issues that pass a date filter, rather than reading every field returned by the connector.
That is the central idea behind Claude Code Mode, an MIT-licensed plugin that lets Claude write one JavaScript program to call MCP tools, filter their responses, and join results before returning a final value to the model. It changes where intermediate data gets processed, without claiming to eliminate the underlying connector calls.
The project, published by GitHub user gabe4coding and introduced through a Show HN submission, is a third-party addition to Anthropic’s Claude Code, not an Anthropic product announcement. Its appeal is an immediately testable workflow for tool-heavy sessions. Its limits are equally important: the token-saving and isolation claims are project claims, not independently validated findings.
One Program Changes What Claude Has to Read
MCP, short for Model Context Protocol, provides the connector interface used here to reach external tools. The plugin targets workflows where those tools return more information than the model needs for its answer.
The project’s README describes the conventional sequence as individual tool calls whose full results enter the model’s context. Code Mode instead asks Claude to express the task as a program. That program can make tool calls, retain intermediate responses, perform transformations, and return a smaller result.
The documented Jira example searches for the user’s open issues, computes a cutoff of 14 days, filters on each issue’s update timestamp, and returns just its key and title. The model gets the shortlist, not the complete records used to produce it.
For a multi-step task, the same approach can combine results before exposing them to Claude. A program can retrieve records, call another tool using selected identifiers, and join the responses inside the sandbox. The model writes the processing logic without having to read every intermediate record.
This is a context-management strategy, not data compression in the usual sense. The source records still exist, and the tools still return them. The plugin keeps that intermediate material outside the model’s conversational context.
There is a corresponding loss of visibility. If the program returns an incomplete or incorrectly filtered answer, Claude cannot inspect omitted records from that return value alone. Developers should make the output sufficiently informative to check, perhaps including source identifiers, relevant timestamps, or counts alongside the answer.
The Sandbox Boundary Is Conditional on the Host
According to the sandbox description, the JavaScript program runs in a separate Node process with no filesystem access and a CPU limit. The README also says it has no network access on macOS, and on Linux systems where unshare -rn works.
Those are specific boundaries, not a universal promise that generated code cannot affect anything outside its process.
The network restriction has an explicit platform condition. A developer assessing the plugin should establish whether the restriction applies on their machine, rather than treating “sandboxed” as an identical guarantee across environments.
The CPU limit is also narrower than a complete resource-isolation claim. The cited overview does not establish a comprehensive memory limit or other resource guarantees. Those should not be inferred from the existence of a CPU budget.
Most importantly, sandbox network isolation does not disable MCP connectors. The program’s purpose is to request tool calls. An allowed connector can still reach the systems it serves or perform actions permitted by its configuration.
That creates two boundaries worth evaluating separately: what generated JavaScript can do directly inside its process, and what it can request through MCP. Restricting the first does not remove the need to constrain the second.
The README documents the intended protections. It does not, by itself, prove that the implementation withstands adversarial code or every host configuration.
Each MCP Call Still Meets the Permission Rules
The project says that every MCP call made by the program receives Claude Code’s normal permission check. Moving a sequence of calls into JavaScript is therefore not described as granting blanket authorization to everything that program requests.
This distinction matters for programs that mix reads and writes. Approving one operation should not be interpreted as permission for unrelated connector actions merely because they appear in the same run.
A permission check does not necessarily mean a fresh human prompt, however. Anthropic’s permission-mode documentation explains that modes establish a baseline, with permission rules layered on top to pre-approve or block particular tools. The oversight a user sees depends on those settings.
The plugin’s quick-start guidance specifically tells auto-mode users to add allow rules for their MCP tools first. That instruction should be read narrowly: approve the tools needed for the task, not an unnecessarily broad collection of connector capabilities.
One JavaScript run also does not make the workflow transactional. The launch description does not establish atomic execution or rollback across MCP calls. If an approved tool changes external state and a later step fails, developers should not assume the earlier action is undone.
For an initial evaluation, read-only tools offer a clearer test of filtering, joining, and permission behavior without introducing the same risk of partial changes.
Hints and Saved Functions Have Their Own Approval Gates
Claude Code Mode includes two reuse mechanisms that deserve attention beyond the sandbox.
Server hints are short notes about an MCP server’s result formats, required arguments, and limits. They help Claude write a program without first examining every possible response. The model can propose a new hint or removal of an incorrect one, but the user must approve the change.
Saved functions let the model propose working portions of a program for reuse in later sessions. The README says the user reads the code and approves it.
These gates matter because both mechanisms can influence future work. A mistaken hint may lead later programs to misunderstand a response. A saved function may carry assumptions about fields, filters, or tool behavior into another session.
Approval is an opportunity for review, not proof of correctness. For a hint, check the claimed schema and limits against the connector. For a saved function, inspect its tool calls, arguments, selection logic, and returned fields. Code that produced the expected result once may still be unsuitable for reuse.
The useful separation is between permission to perform a tool operation now and approval to retain guidance or executable logic for later.
Installation Is Simple; Evaluation Should Be Deliberate
The documented requirements are Claude Code and Node.js 22.13 or later. Installation uses these commands inside a Claude Code session:
Sources
- Claude Code Modegithub.com
- Show HN submissionnews.ycombinator.com
- permission-mode documentationcode.claude.com
