Claude Code 2.1.323 Adds Code Mode for JavaScript Tool Calls

• Claude Code 2.1.323 shipped November 12 with an experimental Code Mode that writes JavaScript to call tools

• Code Mode is opt-in, and the public docs page for it still returns a 404 as of this week

• Plugins can now declare a supported version range with engines in plugin.json, so a mismatched install fails loudly

• The release also shipped 195 bug fixes and made /security-review ask before it runs instead of starting on its own

On November 12, Anthropic shipped Claude Code 2.1.323 with an experimental feature that changes how Claude talks to its own tools. Instead of calling them one at a time, Claude can now write a short JavaScript program that calls several of them in a single pass. It's opt-in, the public docs for it aren't live yet, and the same release tightened two smaller things most solo builders will feel long before they ever touch Code Mode.

What Changed in Claude Code 2.1.323?

The changelog lists four things for this release. Code Mode is the headline: an experimental, opt-in feature where Claude writes JavaScript that calls its tools instead of issuing each call on its own. Plugins can now declare a supported Claude Code version range with an engines field in plugin.json, so an incompatible install fails with a clear message rather than breaking halfway through a session. /security-review now asks before it runs rather than kicking off automatically. And organization settings requests no longer get routed through a proxy that's set only by the ALL_PROXY variable, which had been redirecting that traffic for anyone who'd set the variable for some unrelated tool.

Then there's the unglamorous part: 195 bug fixes. The one called out by name is /compact summarizing away unanswered messages, which is exactly the kind of bug you don't notice until a conversation you thought was intact is missing the one question nobody got to answer.

I checked the official changelog directly for this piece rather than trusting a summary, since release notes get paraphrased into something slightly wrong more often than you'd expect. The four items above are exactly what it says, no more. Everything else you'll read about this release today, including the confident explanations of how Code Mode works internally, is somebody filling in gaps that Anthropic hasn't filled in yet.

No new model. No new pricing tier. Just a maintenance release with one experimental idea bolted to the side of it.

That makes it easy to skip, and I think skipping it would be a mistake. Code Mode is a real change in how Claude executes multi-step work, and the shape of that change is worth understanding now even if you leave the feature switched off for another month.

How Does Code Mode Actually Work?

Normally, when Claude needs to call three tools in a workflow, it calls the first, waits for the result, calls the second, waits again, and so on. Each call and its result round-trips through the conversation. That's simple and easy to reason about, but it's also slow when a task genuinely needs several calls chained together, and it burns context on intermediate results nobody needed to see in full.

Code Mode changes the shape of that. Instead of issuing calls one by one, Claude writes a JavaScript program that calls the tools itself, runs it as a single unit, and comes back with a consolidated result. Picture a task that touches ten files, checking a condition in each one and acting only on the files that match. Call by call, that's ten round trips. As one script, it's one.

Now the awkward part. I tried to read the dedicated docs page for it, at code.claude.com/docs/en/code-mode, and it returned a 404 this week. The changelog entry itself is one line. That means the exact scope of Code Mode, which tools it can reach, and how it interacts with your existing permission rules aren't written down anywhere public yet.

It's early. The feature exists and is real, confirmed straight from the official changelog, but the fine print isn't published.

Turning it on is also not a global flip. The changelog describes it as opt-in, enabled per session or per organization, not a default that changes what happens the next time you open a terminal. That matters for anyone managing more than their own single account, since it means nobody wakes up tomorrow to a different tool-calling model without choosing it first.

I'd also expect the performance story to be more nuanced than "faster." A single script replacing ten round trips should cut wall-clock time on genuinely chained tasks. A task that was never bottlenecked on round trips in the first place, say one tool call followed by you reading the result and deciding what's next, won't feel any different, because there was nothing to batch.

Is Code Mode Worth Turning On Yet?

Not for anything that matters, not this week. I'd try it in a disposable session on a low-stakes task, the kind where you wouldn't mind if it did something unexpected, just to see what the execution actually looks like. That's a different thing from turning it on for a workflow that touches files you'd be annoyed to restore from a backup.

The reason is simple: permission rules are how Claude Code stops a tool call it shouldn't make. If Claude is now writing a script that calls several tools inside one execution, I want to know, in writing, how that script's calls get checked against my settings.json rules before I trust it with anything real. Right now I don't know that, because the page that would tell me doesn't exist yet.

This isn't a knock on the feature. Fewer round trips for genuinely chained, multi-step work is a good direction, and I'd use it happily once the permission story is public and I've watched it behave a few times. I just don't think "experimental, opt-in, docs still 404ing" is the moment to point it at anything with consequences.

If you do try it, watch what happens on a call Code Mode would normally need to ask you about. That single test will tell you more about whether it's ready than anything in a changelog entry.

One test beats a dozen guesses here.

I'd also keep an eye on how it reports what it did. A script that calls five tools and comes back with one consolidated result is convenient, but it also means five individual actions got compressed into a summary. If something in the middle of that script went sideways, I want the log to say so clearly, not bury it inside a result that reads as "done."

What Should Solo Builders Do About the Other Changes?

Update regardless of Code Mode. The /compact fix alone is worth it: losing an unanswered message to a summarization pass is the kind of silent failure that costs you an hour before you even notice it happened, usually right when you go back to answer the question that's no longer there.

/security-review asking before it runs is a small change with an outsized effect on anyone running close to auto mode. I'd rather confirm a scan is starting than have it kick off mid-task on files I didn't expect it to touch. It costs one extra keystroke and buys back a decision point I didn't know I'd lost.

The engines field in plugin.json matters if you maintain any Claude Code plugin, even a small one you only use yourself. Before 2.1.323, a plugin built against an older or newer Claude Code than the one running it could fail in confusing ways, something half-working with no clear reason why. Declaring a version range turns that into a clear error instead. If you've written even one plugin for your own workflow, this is a five-minute addition worth making the next time you touch that file.

The ALL_PROXY fix is the smallest of the four for most solo builders, relevant mainly if you've got that variable set globally for some other tool and never realized Claude Code's organization settings requests were riding along on it.

Small fix. Genuinely painful to debug if you don't know it exists.

The practical version: update this week, then check claude --version instead of assuming the update actually landed. The number I'd hold onto from the changelog is 195, as in 195 bug fixes in a single point release. That's the real content here, and it's reason enough to update even if every new feature in 2.1.323 is irrelevant to how you work.

What I'd wait on is anything that depends on Code Mode behaving predictably. "Experimental" is Anthropic's own word for it, and experimental features change shape between releases. Building a workflow on one today usually means rebuilding it in a month.

This follows 2.1.321, which touched permission handling for a different case, and 2.1.319, which was the last release in this run to change how Claude Code handles multi-step, multi-call work. Code Mode is a bigger swing at that same problem than either of those.

Bottom Line

Take the update for the bug fixes and the /security-review prompt change alone; those help regardless of what you do with Code Mode. Try Code Mode itself in a throwaway session if you're curious, on something you wouldn't mind seeing fail, and treat anything it does as unverified until the docs page exists and tells you how it checks permissions.

If you maintain a plugin, add the engines field while it's still a small edit rather than a confusing bug report later. Everything else here is maintenance, the kind that doesn't show up in a highlight reel but saves you from the one bug that eats an afternoon.

What I'd watch over the next few weeks is whether the docs page shows up and what it says about permissions. A feature that batches tool calls into one script is only as trustworthy as the rules it honors inside that script.

One question to sit with before you flip it on in your own setup: if Code Mode ran a script that called four tools, and one of those was something you'd normally be asked to approve, would you be able to tell from the result that it happened at all?