claude-code 2.1.232 Enables Agent Forks

claude-code v2.1.232 is an open-source release of Claude Code, Anthropic’s coding agent for the terminal, IDE, and GitHub. It deals with a practical problem: Claude Code subagents and live sessions need to coordinate without making you copy context around by hand. The practical answer to how to enable agent teams in claude code is now less about setup and more about using the new defaults carefully on one repo first. The takeaway: agent forking became the interesting default, while session naming, cross-session messages, and GitLab integration got safer.

Follow the new default: forked subagents inherit context

The headline change is that subagent forking is now on by default.

A subagent fork is a Claude Code subagent started with subagent_type: "fork" that inherits the full conversation and prompt cache from the parent session. That matters because the child agent starts with the same working memory as the parent, instead of needing a long recap prompt or a manually pasted brief.

In a real repo, that changes the feel of parallel work. You can ask one subagent to inspect the API route, another to read the migration path, and another to draft the test changes, without treating each one like a blank chat window.

The trap is assuming inherited context means inherited judgment. A fork can see the conversation, but it still needs a narrow job. “Review the checkout flow for null-account edge cases” is much better than “help with payments.”

A small convention helps:

Agent job: inspect only src/billing and tests/billing.
Do not edit files.
Return: risk list, missing tests, and one suggested patch boundary.

That is not heavy process. It is just a clear handoff receipt.

Use session names as a messaging boundary

v2.1.232 also makes live Claude sessions easier to address.

You can type @ in the prompt to mention another Claude session by name. Claude then uses SendMessage to reach that named session directly. The release also changes SendMessage so a bare name works when it exactly matches one live session, instead of forcing a confirmation step with a ref first.

That is a nice bit of friction removal. If you have a session named api-review, you can ask the current session to send it a question without leaving your flow.

The rough edge is naming. Exact-name delivery is only friendly when names are unique and human-readable. v2.1.232 helps by keeping interactive sessions on one machine uniquely named: if you start or rename a session to a name already in use, Claude Code gives it a name-word-word variant and tells you.

Do not build a workflow that depends on casual names like main, test, or fix. Use names that describe the boundary:

api-review
billing-tests
docs-pass
release-notes

This is also where the release connects back to the earlier remote-control work. If you followed Claude Code 2.1.229 Stabilizes Remote Control, v2.1.232 feels like the next tightening pass: less ambiguity, more direct routing, and fewer “which session did I just message?” moments.

Check the quiet safety changes before you celebrate

The release is not only about Claude agents talking to each other.

v2.1.232 adds /config rows for Dialog expiry and Messages from your other sessions. The second setting controls cross-session inbound behavior: accept, hold, or refuse. That is the knob to inspect before you let sessions message each other freely.

A sensible first setting is hold. It lets you see the feature without turning every live session into an interrupt target. Once you trust the naming pattern, move only the sessions that need it to accept messages.

There are also integration safety fixes. The release adds secret redaction for several GitLab, GitLab Inc.’s DevSecOps platform, token families including glrt-, gloas-, glptt-, glagent-, glimt-, glsoat-, glcbt-, glft-, and glffct-. It also fully redacts routable glpat- and gldt- tokens.

That is the kind of changelog line developers should actually read. Agent coordination is useful, but logs and prompts become much less forgiving when multiple sessions are sharing context and sending messages.

The release also says the glab CLI config store now gets the same sandbox and credential-path protection as gh. For plugin marketplaces, bare gitlab.com repository URLs, including nested subgroups, now clone like github.com URLs.

The trap is treating marketplace cloning as a trust signal. Easier install paths are not the same as reviewed behavior. If a plugin bundles commands, hooks, MCP servers, skills, or agent definitions, read the boundaries before running it in a real repo.

Try agent teams on one small repo

When people ask how to enable agent teams in claude code, v2.1.232 gives a good first experiment: start with Claude Code agent teams on a repo where the blast radius is boring.

Pick something like a docs site, a small internal package, or a service with fast tests. Do not start with the monorepo migration that already scares everyone.

Use this simple command workflow:

1. Open the repo and start Claude Code.
2. Name the main session something clear, such as docs-main.
3. Open /config.
4. Set Messages from your other sessions to hold.
5. Start one forked subagent for read-only review.
6. Start one separate session named docs-tests or docs-links.
7. Use @docs-tests from the main prompt to ask one specific question.
8. Review the held inbound message before acting on it.

Add one MCP permission note before the test if your repo has connected services:

MCP boundary for this experiment:
- Read-only docs/search tools are allowed.
- No write-enabled issue tracker, Slack, database, or GitLab actions.
- Human applies code changes after reviewing the diff.

That note is deliberately small. You are not designing a program. You are checking whether the new session and subagent behavior helps you finish one ordinary task with less copy-paste and fewer confused handoffs.

If you keep shared repository memory, a concise CLAUDE.md can help by naming the test command and review norm. Keep it durable: “Run pnpm test:docs before suggesting docs-link changes” is useful. “Today we are trying v2.1.232” does not belong there.

For broader conventions around repository memory, skills, and agent boundaries, see the related training topic.

What changed and what to test

The best first result is boring: one forked review agent, one named session, one held inbound message, and one diff you can explain.

Common questions

• Is v2.1.232 enough for how to enable agent teams in claude code?

  Yes, it covers a key part of the experience because forked subagents now inherit conversation context by default. You still need to create a narrow job boundary, check /config for cross-session message handling, and test on a small repo before trusting the pattern for bigger work.

• What changed for claude code subagents in this release?

  The important change is that subagent_type: "fork" subagents now inherit the full conversation and prompt cache by default. That makes parallel work less repetitive, because child agents can begin from the parent session’s context instead of needing a long summary prompt.

• Are Claude Code agent teams the same thing as the Claude Code Agent SDK?

  No. Claude Code agent teams are an interactive workflow inside Claude Code, using subagents and sessions to split work. The Claude Code Agent SDK is a separate developer surface for building agentic integrations, so do not assume SDK setup is required just to try v2.1.232’s session behavior.

• Should I allow messages from all other Claude sessions?

  Not at first. Use the new /config row for messages from your other sessions and start with inbound messages on hold. That gives you visibility while you learn the naming pattern and avoids surprise instructions landing in the wrong working session.

• Does the GitLab redaction change make plugins automatically safe?

  No. Redaction reduces the chance that GitLab token strings leak through logs or prompts, and the release improves glab credential-path protection. Plugin safety still depends on what the plugin bundles: commands, hooks, MCP servers, skills, and agent definitions can all change behavior.

Best ways to use this research

• Best for: Claude Code users who already use subagents and want to understand why v2.1.232 changes the default coordination model.
• Best first artifact: A one-repo experiment with one forked subagent, one named session, cross-session messages on hold, and a small MCP permission note.
• Best comparison angle: Compare “forked subagent with inherited context” against “fresh session with a pasted brief” on the same code review task.
• Best caution: Treat easier session messaging as a routing feature, not a substitute for clear names, narrow prompts, and human review.

Further reading

• Claude Code — getting started
• Claude Code — skills
• claude-code — source

Next step

Try v2.1.232 on one small repo with cross-session messages set to hold. Keep the experiment boring enough that you can tell whether the new agent behavior helped or merely made the session graph busier.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.