Claude Code makes background work easier to pick up again

Today's most useful Claude signal is not a huge new model. It is Claude Code getting better at something much more ordinary: finding your way back to work that is already running.

For small teams that let an AI agent fix a bug, write tests, or clean up documentation in the background, this is the difference between "I will start over" and "I can pick up the right thread, review it, and move on".

What Claude Code 2.1.144 changes

Claude Code is Anthropic's coding agent for the terminal, VS Code, web, the Desktop app, and other development environments. A coding agent can read a codebase, propose edits, run commands, and keep a multistep development task together.

In version 2.1.144, published on May 19, 2026, Anthropic added support so /resume also shows background sessions started with claude --bg or from Agent View. They are marked with bg, and background agent completion notifications can now show how long the work took.

The same release also makes /model more local: a model change now applies to the current session, while pressing d in the model picker sets the default model for new sessions. That sounds small, but it reduces the chance that a quick test session accidentally changes the model for the next serious job.

Source: Claude Code changelog 2.1.144.

Source: GitHub release v2.1.144 and npm registry for @anthropic-ai/claude-code.

Why it matters in practical work

Background agents are only useful if someone can follow up on them. Otherwise, you just get more half-finished threads.

Picture a small product or consulting business. One person asks Claude Code to update a proposal template, another starts a test job for an integration bug, and a third asks the agent to draft release notes. If all of that lives in separate chat histories, follow-up gets messy. If each job can be resumed, seen as bg, reviewed, and tied to the right directory, it starts to feel more like a work queue.

This is where human control belongs. Not by watching every token while the agent works, but by deciding what it may do, what it may not do, and what evidence it must show before anything is merged, sent, or published.

For Hammer readers, this is a clear Tool Forge question: which AI jobs should be allowed to run in the background, how should they be named, and who owns the final review? Skill Forge follows close behind, because the team needs simple habits for not losing track of what the agent did.

The MCP signal: the tool list has to be complete

Model Context Protocol, MCP, is an open standard for connecting AI apps such as Claude Code and Claude Desktop to external systems, for example files, issue trackers, databases, and internal tools.

In the same Claude Code release, Anthropic fixed paginated MCP tools/list responses only returning the first page. It is a technical changelog line with a plain practical meaning: if an agent needs to choose among connected tools, it should see the whole list, not just page one.

Source: Claude Code changelog 2.1.144.

Source: MCP: What is the Model Context Protocol? and MCP architecture overview.

What to test today

Do not run the first attempt in a critical customer codebase. Choose a harmless internal repo, documentation folder, or test environment. The goal is not to let Claude build everything alone. The goal is to see whether you can park, resume, and review an agent job without losing context.

A good first exercise:

• start one small background job with a clear boundary
• resume it with /resume
• check which model the session is using
• ask Claude to show changes, tests, and remaining risks before you accept anything

If it feels boring, you picked the right level. Background agents should become manageable before they become ambitious.

Try this prompt this week

Use it in Claude Code in a non-critical codebase. Ask Claude to plan first. Do not automatically allow destructive commands, publishing, secrets, or production data.

You are my Claude Code work lead for a background job.

Context:
- Codebase or folder: [briefly describe]
- Goal of the job: [for example clean up README, write missing tests, investigate a bug report]
- Things you must not do: [for example no deploys, no database changes, no external API calls]
- Human reviewer: [name/role]

Before changing anything:
1. Propose one background-safe job that can be paused and resumed.
2. Write a short "resume note" I can recognize in `/resume` later: goal, files, risks, and next checkpoint.
3. Say which model or effort level is enough for the job, and what definitely does not need the most expensive model.
4. List the exact commands you want to run and why.
5. Define the stop rule: when should you stop and ask me instead?

When the job is done, respond with:
- files changed
- tests or checks run
- what I need to review manually
- what remains if I resume the session later

A good result looks like this:

• the job is small enough to review in 10 to 15 minutes
• Claude leaves a clear resume note
• risks sit next to the changes, not hidden at the bottom
• you can reject the result without untangling a huge mess

What we are watching next

Claude Code is moving toward more work queue and fewer one-off chats. Agent View, background sessions, MCP connections, plugin information, and clearer model choices all point in the same direction: AI work needs operating habits.

That is a good thing. A little less magic, a little more order. For Swedish teams that are already busy, that difference can decide whether the AI agent becomes a helper or just another tab nobody dares to close.