Claude Code 2.1.323 lets Claude call tools via JavaScript

Claude Code 2.1.323 came out on November 12 with Code Mode, an experimental opt-in in which Claude writes JavaScript to call its tools. The same release raises the context window Claude Code assumes for a model ID it doesn’t recognize from 200K to 1M tokens, so sessions on another vendor’s smaller-window model can run past their real limit. If you run such a model, the release notes on GitHub say to set CLAUDE_CODE_DISABLE_1M_CONTEXT=1 before those sessions fill. Once full, they can fail every turn until /clear.
Code Mode stays off until you turn it on. An organization can also turn it off for everyone, and the Code Mode documentation covers both. The other addition most users will notice is a new menu. When a model needs usage credits that are turned off or used up, Claude Code now offers to stop, switch to usage credits or upgrade.
Models Claude Code doesn’t recognize
The 1M assumption applies only to model IDs Claude Code doesn’t recognize. Besides the environment variable, the notes name a second fix: /autocompact, which makes Claude Code compact the conversation earlier.
Other changes in this release also affect people who run Claude Code through gateways or other providers. Auto mode behind a gateway at ANTHROPIC_BASE_URL now refuses any model whose gateway name contains “haiku”, except claude-haiku-5-5. Haiku 4.5 was already refused. The Claude apps gateway’s /v1/models now states max_input_tokens, but only for models whose context window is certain on every upstream. On Amazon Bedrock, the error for a model your account can’t use now tells you to enable the model. It used to tell you to refresh your AWS credentials. The maximum for CLAUDE_CODE_OVERLOADED_RETRY_MAX_DELAY_MS goes from 64000 to 300000.
What may break after updating
Claude Code’s own ripgrep and most of its internal git commands now run without most of its sign-in tokens and API keys. A credential helper or hook that runs under one of those git commands won’t find them anymore. Organization settings and policy requests no longer go through a proxy set only by ALL_PROXY. If your network needs a proxy for them, set HTTPS_PROXY.
The sandbox on macOS and Linux is stricter about git. git worktree add, move and remove now fail with a read-only error. So do commits in a worktree the session wasn’t started in or given, even when that worktree is inside the project. On macOS, Linux and WSL, the sandbox ignores write access granted through a symlink in a writable folder if the link points somewhere else or to a missing path. Grant the real path instead. Worktree creation also refuses checkouts whose .git folders are links or contain hard links, such as git-new-workdir layouts and cp -al copies. The notes say to use a plain clone.
Hook authors should check two changes to how permissions are decided. Suppose a PreToolUse hook returns “allow” and the tool’s permission check then fails with an error. Claude Code now decides the call as if no hook had answered. If the check fails on input that a PermissionRequest hook rewrote, Claude Code asks again. Where nobody can answer, it refuses the call.
Other changes can break existing setups:
- Start-up stops when a
--settingsfile isn’t valid JSON and has asandboxkey, even one that turns the sandbox off. - Approvals for project MCP servers in
.mcp.jsonmust match the server’s exact name. An entry spelled differently triggers the approval prompt again. - Marketplace and plugin installs fail when a git submodule isn’t on the commit its repository records.
- Sessions on the same machine can send each other about 100,000 messages without a prompt from you, up from about 20. For a Claude Desktop Code tab session, the limit goes from 20 to 100,000.
- On-demand self-hosted runners whose work order was superseded exit with code 1 again. Versions 2.1.321 and 2.1.322 had changed it to 0.
Permission prompts that didn’t fire
Bash permission checks get the longest run of fixes, and once again several of them close cases where a command ran without a prompt. Version 2.1.321 fixed a similar gap: a read-only Bash command could run outside the sandbox without a prompt. The cases fixed this time:
- Allow rules with a wildcard attached, such as
Bash(ls*), sometimes skipped the prompt. A rule that names a variable, such asBash(NODE_ENV*), now asks. Start-up also warns about allow rules with a*in a variable’s value, such asBash(PORT=* npm run dev). - Allow rules written with combined sudo flags sometimes skipped the prompt. Deny and ask rules missed some commands run through sudo, env and similar wrappers.
- One check looked at an
rmfrom the wrong folder and skipped the dangerous-removal prompt under bypass permissions or a Bash allow rule. - Write and Edit could write to a path covered by a Read deny rule, and the Bash sandbox could switch off during a session.
- Some commands ran without a prompt for zsh users with certain non-default shell options. On Windows, some file-reading commands given a wildcard or a list of files did the same.
Two fixes change what happens at start-up. With --permission-mode auto or defaultMode: auto in settings, Claude Code used to start in a mode that could allow more when auto mode was unavailable. It now starts in Manual mode, which asks first. Before this release, claude -p and the Agent SDK ran Bash unsandboxed when the settings that turn the sandbox on failed validation. This applied to both --settings and SDK settings. Claude Code now stops at start-up and names the invalid setting, so a pipeline with a broken sandbox config fails visibly.
“Don’t ask again” is also narrower now. An allow rule that looks like it holds a secret, or that would be saved to a settings.local.json tracked by git, now lasts only for the session. The tool Claude uses to finish an MCP server sign-in now asks you to confirm, even in bypass and auto modes. In dontAsk mode, where nobody can be asked, the notes point to /mcp.
Plugin and mod authors
Mods also see stricter rules. A *, namespace or negated hook on engine.create now only observes. To add or withhold a $ noun, hook engine.create by name. claude plugin validate now fails a mod whose engine.create hook isn’t written in the one accepted form, but installed mods keep loading. A mod also can no longer reword Claude Code’s own confirmation questions. That fix arrives soon after the November 9 changelog, which made mods Claude writes turn on without asking in auto and bypass modes. Under that change, mods’ own tool calls raise no permission prompt, though deny rules and organization policy still apply.
A plugin’s agent setting is deprecated. It still applies, but it now triggers a warning at startup, in claude plugin list and in claude plugin validate. The subagentStatusLine setting is gone, though settings files that still contain it load as before. MCP_SDK_GENERATION=v1 now runs the v2 MCP client in a compatibility mode, because the v1 client has been removed.
Plugins can now declare which Claude Code versions they support with engines["claude-code"] in plugin.json. Claude Code won’t install, update or load a plugin outside that range, and install and update pick the newest version that fits. claude plugin validate also type-checks a plugin’s TypeScript hooks module now. Each finding is a warning, and --strict turns it into a failure.
Up next
Claude Duet users get 3 invites each, US only
Per a Threads post, Claude Duet users get 3 invites each, plus a free week of Claude Pro for eligible US users. Duet’s background work, like the morning brief, counts against plan usage limits too. Is your Claude plan usually short on limits or left with room to spare?
Related stories
- Claude Code makes Fable 5.2 default at $8/$40 per Mtok
- Cloud sessions in Claude Code now set up your repo
- Claude Code desktop gives each parallel task its own session
- Claude Code Projects admits its whole Pro and Max waitlist
- In Claude Code, a “block” hook could let commands through
- Claude Code Projects threads can now run on your machine
Comments
No comments yet. Be the first.
Join the conversation
Sign in to leave a comment. It appears after moderation.

