claude-code 2.1.223 Tightens Marketplace Permissions

claude-code v2.1.223 is a release of Claude Code, Anthropic's coding agent that runs in the terminal, IDE, and GitHub workflows. Claude Code is an agentic coding tool that can inspect a repo, run commands, edit files, and help with git work through natural language. This release deals mostly with permission boundaries: marketplace allowlists, command approval prompts, workflow sandboxing, and model restrictions. If your real question is Claude Code for teams, the takeaway is simple: test the new boundary behavior before you let agents touch a busy repo.

Read the release as a permissions story

The headline change is not flashy. It is the new owner/* wildcard for the strictKnownMarketplaces and blockedMarketplaces managed settings.

That lets an organization allow or block every marketplace repo under a GitHub owner. For example, a platform group could allow acme-internal/* while blocking an experimental marketplace org in one setting instead of maintaining a long list of repo names.

The trap is that org-level wildcards are blunt. owner/* is easier to maintain than dozens of entries, but it also trusts or blocks future repos under that owner. Treat it like a package registry rule, not like a casual preference.

A useful review question is: “Would we be comfortable with a new repo created under this owner tomorrow?” If not, pin individual marketplace repos instead.

Notice what now warns instead of silently surprising you

v2.1.223 adds a warning when a requested subagent model is restricted and the parent model runs instead. The release names workflow agents, forked skills, slash commands, and resumed background agents as affected surfaces.

That matters because a Claude Code workflow can be larger than the chat you are looking at. A slash command may call an agent. A skill may request a model. A resumed background agent may continue from older state.

The good change is visibility. If a subagent asks for a restricted model, you should now get a warning rather than silently assuming the requested model ran.

The rough edge is that a warning is still something a human has to notice. If you are using Claude Code agent teams in a repo with strict model rules, add one line to the review notes: “Did any agent run under a fallback parent model?” Boring, yes. Useful, also yes.

For skill-heavy workflows, this pairs naturally with the official Claude skills model: skills are reusable packages of instructions and assets, but their activation surface can hide real work behind a compact request. If that is your lane, the earlier research note on book-skills Turns Work Books Into Claude Skills is a good companion read.

Treat teleport as a handoff hint

The release also adds a /teleport hint in cloud sessions, showing how to continue locally with claude --teleport.

That is a nice quality-of-life change. Cloud sessions are useful when work starts away from the local machine, but many engineering tasks still become easier once you are back inside the repo with local tooling, credentials, tests, and shell history.

The trap is to treat teleport as magic state transfer. The release note says the hint shows how to continue locally; it does not say your local environment is now identical to the cloud session.

A practical Claude Code workflow is to make the handoff explicit:

# In the local repo, after following the cloud session hint
claude --teleport

# Then verify local state before continuing
pwd
git status
pytest -q

If the session had changed directories with /cd, this release also fixes a bug where resuming after a mid-session /cd could come back empty. Still, trust the terminal more than the memory of the chat. Check where you are.

Test the security fixes where commands get weird

Several fixes in v2.1.223 are about crafted input. The release says Claude Code fixed a Bash permission bypass where a command could hide parts of itself from permission checks. It also fixed permission prompts so commands padded with tabs or invisible Unicode can no longer hide part of the command from the approval dialog.

That is the kind of bug that only sounds small until you remember what permission prompts are for. The prompt is the moment where a human says, “Yes, run that command.” If the visible command differs from the checked command, the boundary is weak.

The release also fixes workflow scripts being able to use dynamic import() to run code outside the workflow sandbox. And it fixes a gap where an agent definition’s bypassPermissions mode ignored the organization policy that disables bypass permissions.

A concrete check is to keep one intentionally boring test repo with a tiny hook boundary, one slash command, and one workflow script. Do not aim for cleverness. You want a repo where suspicious behavior is obvious.

Example permission note for that repo:

Permission note for v2.1.223 smoke test

Allowed:
- Read files in this repo
- Run `git status`, `git diff`, and the test command
- Edit files under `src/` and `tests/`

Needs explicit approval:
- Shell commands with pipes, redirects, subshells, or encoded input
- Commands containing tabs or non-printing characters
- Any workflow script that imports code dynamically

Blocked:
- Network calls
- Package publishing
- Credential or token inspection

This is not a full policy. It is a small tripwire. Small tripwires catch embarrassing mistakes before larger rules do.

Try v2.1.223 on one small repo

Use one low-risk repository before changing your normal Claude Code workflow. The best candidate is a real repo with tests, a few slash commands, and at least one Claude skill or agent definition, but no production secrets.

For people evaluating claude code for teams, this is the practical section: test the surfaces that changed, not every feature Claude Code has. The related team conventions topic is useful context, but the release itself is about boundaries, warnings, and handoffs.

Keep the experiment short. If the table takes more than an hour to run, the repo is too complicated for this job.

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.

Practical starter checklist

- [ ] Name the Claude Code artifact first: a hook boundary, an MCP permission note, a slash-command workflow, a Claude skill outline, a review checklist, or a concise CLAUDE.md note when repository memory is the topic.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about claude code?

  Start by writing down one visible team rule for Claude Code, not a loose preference. That is the practical core of claude code teams. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Claude Code artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a hook checklist, MCP permission rule, slash-command workflow, skill outline, or concise CLAUDE.md note. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Claude Code teams deciding which hook, skill, MCP boundary, slash-command workflow, review habit, or repository-memory convention to standardize next around “claude-code 2.1.223 Tightens Marketplace Permissions.”
• Best first artifact: turn the named fix into a hook checklist, skill note, MCP permission note, review receipt, or concise CLAUDE.md convention when repository memory is the real topic before the next automated run.
• Best comparison angle: compare the workflow against the current Claude Code handoff, hook behavior, and MCP scope; keep the path that leaves the shortest auditable trail.

Further reading

• claude-code — source
• Claude Code — getting started
• Claude Code — skills
• Claude Code docs: en hooks

What to do next

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.