New Claude Code Features in 2026 and Their Security Implications

The Claude Code features shipping through 2026 do not just make the agent smarter - they change how many actors it runs, where those actors execute, and who approves what they do. In a single year Claude Code gained peer-to-peer Agent Teams, a classifier that adjudicates permission prompts instead of a human, nested subagents running in the background by default, a sandbox with credential masking and strict network allowlists, cross-machine session messaging, and self-hosted execution environments. Each of those is a genuine improvement for the developer, and each is a new surface a security team now has to discover, classify, and govern.

The through-line is the one we have written about for every coding agent: the vendor owns the runtime, but the *fleet posture* - who is running which version, in which mode, with which skills, plugins, and sandbox settings live - is unowned by default. We walked the underlying rules in how Claude Code permissions actually work and the configuration in the permissions and hooks hardening guide. This post walks the 2026 release list and asks, for each addition, what it means for visibility across your fleet. It is the Claude Code companion to the new OpenAI Codex features and their security implications, and it builds on the category-wide argument in securing AI coding agents and CLIs.

Every capability below is real, documented, and shipped. None of it is a flaw. The point is that reach and autonomy grew in the same year, and the fleet posture behind them did not grow on its own.

A new default model, and a much larger context window

Claude Opus 5 rolled out on July 23, 2026 and became the default Opus model in Claude Code, with a 1M-token context window and a five-level reasoning effort setting running from low through max. Claude Sonnet 5 landed earlier in the year as the default model, also with a native 1M-token context. Organizations can now set default models centrally, which surfaces in the model picker as "Org default" or "Role default".

From a security standpoint the interesting fact is not the benchmark - it is that a more capable model with a far larger window is a more capable agent inside whatever sandbox and permission combination a developer has set. A 1M-token context also means far more of your codebase, logs, and pasted material sits inside a single session. The model version and the effort setting become configuration facts you want to read per endpoint rather than assume, because capability changing underneath a policy you set months ago is the quiet kind of drift. The guidance moved with the model: a day after the Opus 5 rollout, Anthropic reported removing over 80% of Claude Code's system prompt with no measurable loss on its own coding evaluations, pushing what it removed into a per-endpoint tree of skills, CLAUDE.md files, and rules files.

Agent Teams: sessions that talk to each other

Agent Teams shipped on February 5, 2026 alongside Claude Opus 4.6, as a research preview gated behind CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. One session acts as a team lead and spawns independent teammates, each with its own context window and tool access. The detail that matters is the topology: teammates communicate peer-to-peer through a mailbox system and a shared task list, rather than only reporting up to a parent.

That is a different security shape from a subagent tree. When one actor's output becomes another actor's input without a human reading it, you have an internal trust boundary with no reviewer at it - the same class of problem we mapped in agent-to-agent trust boundaries. The mailbox is also state on disk: the changelog records a crash loop in which a malformed teammate mailbox message caused repeating errors until the file was deleted by hand. What to govern: treat each teammate as its own actor with its own configuration, and treat the messaging surface as a place where instructions cross between contexts. Answering "how many agents are actually running, and in what configuration" across a fleet is exactly the question in auditing Claude Code across a fleet.

Subagents went background-by-default and three levels deep

Subagents changed materially in 2026. They now run in the background by default, so the main session keeps working while they execute and is notified when they finish. Nested subagent spawning went to depth 3 by default, up from 1, tunable with CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH. Skills declared with context: fork also run in the background by default. Concurrency is capped at 20 by default (CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS), and the old 200-agents-per-session spawn cap was removed outright, so a long-running session no longer refuses new agents.

Put together: a single developer command can now fan out into a tree of autonomous actors, three levels deep, running concurrently, without a human watching any individual branch. Only summaries return upstream, so what a depth-3 agent actually did in its own context is not visible from the top. The governance implication is that the count of actors to inventory is no longer one per session and no longer bounded by a documented cap. What to govern: enumerate subagents as first-class actors, the skills they preload, and the concurrency and depth limits actually in force on each endpoint.

Auto mode moves the approval decision away from the human

This is the most consequential change of the year for anyone who thought of the permission prompt as the control. Auto mode routes permission decisions through a permission classifier rather than a human prompt, and it is now available by default on Bedrock, Vertex AI, and Foundry, where it previously required opting in through CLAUDE_CODE_ENABLE_AUTO_MODE. The classifier defaults to Sonnet 5 for external sessions, validated on the session's first request and pinned for the session. A new autoMode.classifyAllShell setting routes every Bash and PowerShell command through the classifier. Anthropic also kept adding dangerous-code patterns to it, including rm -rf against unresolved variables and tampering with session transcripts, and hardened it so that checks such as dangerous-rm no longer open a dialog in auto mode because the classifier adjudicates instead.

Two changes in the same release stream tell you where the boundary now sits. Auto mode was fixed so it can no longer override a PreToolUse hook's ask decision - a hook's ask now floors the decision at a prompt. And messages sent to other agent sessions through SendMessage are themselves evaluated by the permission classifier before dispatch. Both are the right calls, and both confirm the same thing: an approval that once paused for a person can now be resolved by a model. That can improve consistency, and it also means fewer moments where a human sees what was approved. The default permission mode was renamed to "Manual" across the CLI, VS Code, and JetBrains with a grey badge in the footer, precisely so the active mode is always visible - which is an admission that mode confusion is the risk. The loosest end of this spectrum is covered in what dangerously-skip-permissions really does.

The sandbox gained real primitives, and they are all settings

Claude Code's sandbox got substantially more capable in 2026. sandbox.network.strictAllowlist denies non-allowlisted hosts for sandboxed commands without prompting. Credential files gained mode: "mask" on Linux and WSL, where sandboxed commands read a sentinel copy while the sandbox proxy substitutes the real value on egress, with extract regexes for structured environment values, decode: "jwt" with maskClaims for JWT-aware masking, and awsPairs/sigv4 for AWS SigV4 re-signing. Those masking options require network.tlsTerminate and are honored only from user, managed, or --settings scope, not from a repo-resident file. A sandbox.filesystem.disabled setting skips filesystem isolation while keeping network egress control.

This is genuinely good security engineering, and it is also the clearest illustration of the fleet problem. Every one of those primitives is a setting in a file on a laptop. The changelog itself records that denyRead: "~/.aws/" with a trailing slash was bypassable on Linux and macOS until it was fixed, that filesystem deny entries covering the working directory broke sandboxed commands, and that late-appearing .claude/* symlinks were not reconciled into the sandbox deny-write list. A control that is this powerful and this configurable is exactly the kind you must verify is present and correct on every endpoint rather than assume. What to govern: the sandbox configuration itself, as an inventoried fact per machine.

Cross-session messaging turns the fleet into a message bus

Cross-session SendMessage lets Claude Code sessions message each other on any of your machines, with ListAgents to discover them, on macOS and Linux. It can start a conversation with your Remote Control sessions on other machines by name rather than only replying after they message you first. Managed settings gained crossSessionInbound and dialogExpiry to control the behavior: messages sent to a session running with bypassed permissions are held for approval, while messages to other sessions auto-deliver.

Read that as a defender. A session on one machine can now inject a prompt into a session on another machine, and the receiving session may be running with permissions the sender's machine never granted. Anthropic clearly saw the same thing, which is why inbound messages to bypassed-permission sessions are held for approval and why outbound messages now pass through the permission classifier. The residual governance question is the familiar one: crossSessionInbound is a managed setting, so it only protects the endpoints that actually received managed settings. What to govern: which endpoints have cross-session messaging reachable, and what the inbound policy is on each.

Self-hosted runners and Remote Control move where sessions execute

Self-hosted environments arrived in August 2026 in public beta for Team and Enterprise plans. claude self-hosted-runner turns your own machines or containers into a place where Claude Code web, mobile, and desktop sessions can run, so a session started from a phone or a browser executes inside your network, next to your internal services and toolchains. Remote Control matured alongside it, letting web and mobile clients attach to sessions, see permission prompts, and approve them, with auto-start controllable at user scope and repo-local settings able to turn it off but not on.

For a security team this cuts both ways, and it is worth being fair about it. Running sessions on infrastructure you control, with your own egress controls and compliance tooling, is a real improvement over an opaque hosted environment. It is also a new execution surface: a runner is a long-lived host that accepts and executes work initiated elsewhere, and an approval prompt can now be answered from a phone by someone who is not sitting at the machine. The comparison of how remote and unattended modes differ across agents is exactly the ground covered in Claude Code vs Codex vs Cursor permission models.

Plugins, marketplaces, and the archive source

A plugin remains the densest single trust decision in Claude Code: one versioned bundle that can contain skills, subagents, slash commands, hooks, output styles, and MCP server definitions. Plugin distribution grew in 2026. A new archive plugin source installs plugins from a zip over HTTPS without git or npm, with optional SHA-256 pinning. Plugins installed through /plugin now activate immediately when safe instead of always requiring /reload-plugins. On the governance side, strictKnownMarketplaces and blockedMarketplaces gained owner wildcard entries ("owner/*") so an admin can allow or block every marketplace repo under a GitHub org at once.

The archive source is the item to sit with. Installing from a zip over HTTPS removes the git history, the repository, and the review surface that came with them - and SHA-256 pinning is *optional*, which means an unpinned archive install is a supply-chain decision with no integrity guarantee attached. This is the same pattern we trace in AI supply chain attacks, and it is why skills deserve independent scanning, covered in the agent skills security primer and in our work on the NVIDIA SkillSpector scanner. What to govern: expand each installed plugin back into the skills, subagents, hooks, and MCP servers it contributes, record its source and whether it was pinned, and enforce the marketplace allowlist as a floor. Which skills are worth trusting at all is the subject of the top AI agent skills of 2026.

Worktree isolation: a boundary that needed hardening all year

Worktree isolation is how Claude Code keeps a background session or an isolation: 'worktree' subagent from touching the main checkout. Across 2026 it was repeatedly tightened: isolated subagents could redirect git into the shared checkout through git -C, --git-dir, or GIT_DIR/GIT_WORK_TREE; isolated subagents could run git-mutating commands against the main repo; worktree creation could follow a repository-committed symlink at .claude/worktrees and create files outside the repository; and on Windows worktree removal could delete files outside the worktree through an NTFS junction. The most recent fix extends isolation so that it now applies to file edits and Bash in every session type, not only to git operations.

None of this is a criticism - this is what an isolation boundary looks like while it is being hardened, and every one of those was found and fixed. The defender's takeaway is narrower and more useful: isolation boundaries are version-dependent. A fleet running mixed Claude Code versions is a fleet where the same setting means different things on different machines, which makes the installed version itself a security-relevant fact to inventory. That is part of the broader picture in the Claude Code harness attack surface.

Managed settings became server-delivered

Managed settings remain the enterprise control point, sitting above command-line flags, project settings, and personal settings. In 2026 they gained server-delivered configuration, so policy can reach a developer when they authenticate rather than only through an MDM-pushed managed-settings.json. The two now compose rather than compete: server-delivered settings no longer disable the env block of a machine-local managed-settings.json, and the admin env merges per key. Approval prompts were also changed so they do not reappear after a re-login or an org switch when the org settings are unchanged.

Server delivery is a real improvement, because it works on BYOD machines where you cannot push a file. It does not change the underlying limit: managed policy only exists where it was actually received, and an unenrolled laptop running Claude Code has none of it. Getting the policy onto every endpoint is a rollout problem covered in deploying Claude Code across a fleet; confirming it arrived is a visibility problem.

The 2026 features and what each one means for governance

How Anomity governs Claude Code across the fleet

Every feature above shares one property: it is scoped to a process on a single endpoint, and nothing centrally records which version, which skills and plugins, which sandbox settings, or which permission mode is live. Anomity closes that gap at the layer where the artifacts actually sit. A lightweight, unprivileged Endpoint Sensor runs on every managed endpoint - Windows, macOS, and Linux - and discovers and inventories eight AI artifact types: AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs. That maps directly onto the Claude Code surface, so a plugin installed from an archive is expanded into the skills, subagents, hooks, and MCP servers it actually contributes (fleet inventory).

The Sensor sends metadata only over HTTPS to Anomity Cloud - never your source code or prompts - and secrets are redacted on the endpoint before anything leaves it. At the PreToolUse hook, Anomity returns allow, deny, or log on each tool call before it runs, which turns an in-session approval, or an auto-mode classifier decision, into an enforced org-wide policy at the trust boundary (allow/deny/log at the hook). Change events are captured as skills, plugins, and CLIs are added or modified, so a newly installed archive plugin or a freshly enabled Agent Teams flag is a fact you see, not a surprise.

Every decision lands in a queryable 90-day audit trail and routes to your SIEM, Slack, email, or Jira, so an approved escalation is no longer a private moment in one terminal (audit and outcomes). Anomity is SOC 2 Type II, and it complements - it does not replace - your EDR, XDR, DLP, network, and GRC controls. See how it works for the deployment model, the compare view for where it sits alongside adjacent tooling, and the AI security framework for the program-level framing.

You can't govern what you can't see - and every Claude Code feature that ships widens what you can't see by default.

Claude Code's 2026 releases are good engineering, and much of the year's work was Anthropic hardening its own boundaries. The point is that autonomy and reach grew in the same year the approval decision moved from a person to a classifier, and the fleet posture behind that did not grow on its own. Inventory the versions, the skills, the plugins, the sandbox settings, and the modes; enforce policy at the hook; keep the audit trail. If closing that gap for Claude Code is yours to own, book a 30-minute demo.