Claude Code makes plugins and background agents easier to control

When Claude starts using more tools, the useful question changes. It is no longer just whether it can do the work. It is whether we know what it connected to, what it costs, and who can stop it. That is today’s practical Claude signal: Anthropic is not only improving answers. It is also making Claude Code behave more predictably when plugins, MCP servers, and background agents become part of daily work.

What changed in Claude Code 2.1.143

Claude Code 2.1.143 shipped on May 15. It is a technical release, but it points to a very normal business problem: AI tools are moving from chat boxes into work environments that need operations, permissions, and cleanup.

A few changes stand out:

• Plugins can no longer be disabled blindly if another enabled plugin depends on them. Claude Code now gives a disable-chain hint that can be copied.
• The plugin marketplace shows projected context cost per turn and per tool invocation. Context cost means how much of the model’s working memory and token budget a tool is expected to use.
• claude agents can now be launched with more defaults for model, effort, permission mode, MCP config, and plugin directories.
• Background sessions preserve more of their settings when they wake up again, including MCP config, model choice, and fallback model.
• Worktree cleanup no longer falls back to rm -rf when normal git worktree removal fails, reducing the risk of losing ignored or in-progress files.

Source: Claude Code changelog 2.1.143 and GitHub release v2.1.143

Why this matters beyond developer teams

A plugin is an add-on that gives Claude new abilities, such as reading files, talking to another system, or running a specific workflow. MCP, Model Context Protocol, is an open protocol for connecting AI assistants like Claude to external tools, data, and workflows in a more standard way.

For a small company or school, this is less dramatic than it sounds. It turns into everyday questions:

• Which connections may Claude use when someone drafts a customer proposal?
• Which tools may run in the background while a person does something else?
• What happens if one plugin depends on another?
• How do we notice when a tool uses too much context or money?

That is often what decides whether AI becomes a useful coworker or just another messy app in the pile.

Remote MCP and custom connectors make control more important

The MCP documentation explains how Claude can connect to remote MCP servers through Custom Connectors. A remote MCP server is an internet-hosted service that exposes tools, resources, or prepared prompts to Claude. Custom Connectors are the bridge in the Claude interface where a user adds the server, authenticates, and controls which tools may be used.

That makes Claude more useful in real processes, but only if someone owns the connections. A consultant who lets Claude read proposal notes, CRM context, and past delivery material does not need more magic buttons. What helps is a simple list: what each connection does, what data it can see, who approves changes, and how to turn it off without breaking everything else.

Source: MCP guide to remote servers and Custom Connectors

Try this prompt this week

Use it in Claude desktop or Claude in the browser if you are planning connectors, plugins, or Custom Connectors. Use it in Claude Code if you already work with plugins, MCP config, or background agents. Do not paste secrets, API keys, or customer data. Describe systems at a level that is safe to share.

You are my AI tool steward. Help me create a simple operating card for the Claude connections, plugins, or MCP servers we are considering.

Workflow: [describe the workflow, for example proposal writing, lesson planning, customer support, or code review]
Tools/connections we are considering: [list them]
Data that may be sensitive: [list without pasting real customer data]
Who should approve actions: [role/person]

Create:
1. A table-free list with each tool, purpose, data access, and risk.
2. Which tools seem to depend on each other and what could break if we disable one of them.
3. Which actions Claude may only suggest, not perform.
4. One simple cost and context question we should answer before using the tool in production.
5. A shutdown plan: how we pause the tool without stopping the whole workflow.

Write for a practical operations owner, not for a developer team.

Good output looks like this:

• You can read the list and understand each connection without technical background.
• At least one human owns approval and shutdown.
• Claude cannot write to production systems without a clear checkpoint.
• You can see which connections should be tested in a sandbox first.

If the list gets long, that is a sign you need Tool Forge, Hammer Automation’s practical work on choosing, connecting, and maintaining AI tools without creating a new mess.

What I would watch next

One flag in Claude Code is not the story. The pattern matters: Claude is getting better ways to manage plugins, background work, permission mode, MCP config, and failures that otherwise become quiet operational problems.

For Swedish teams, the next step is simple: make a small tool register before you connect Claude to more systems. Once the list exists, test one workflow at a time, with human review wherever the output could affect a customer, student, invoice, or published information.