Claude Code release notes: 2.1.198-2.1.199 make background agents reviewable

Claude Code 2.1.198 and 2.1.199 move agent work closer to a real work queue. Subagents now run in the background by default, claude agents can send notifications when a session needs a reply or finishes, and an agent doing code work in a worktree can finish by committing, pushing, and opening a draft PR. The next day, 2.1.199 added the operational part that matters most: errors and incomplete work should no longer disappear quietly.

Source: GitHub release v2.1.198

Source: GitHub release v2.1.199

Claude Code release notes 2.1.198: background agents become a work queue

A coding agent is an AI assistant that can read a codebase, use tools, and propose or make changes across several files. In 2.1.198, subagents run in the background by default. Claude can keep working while they run, and the user is notified when they finish.

The point is not that more things happen at the same time. The point is that more things can be followed up. The release notes say claude agents can now trigger the Notification hook when a session needs input or completes, with the events agent_needs_input and agent_completed. A hook is a rule or integration that runs when a specific workflow event happens.

The same release also says background agents launched from claude agents can now commit, push, and open a draft PR when they finish code work in a worktree. A draft PR is a reviewable pull request that does not yet claim to be ready to merge. For teams, that is a useful boundary: the agent can package the work, but a human reviews it before it becomes a live change.

Source: GitHub release v2.1.198

2.1.199: better error reporting when agent work goes wrong

2.1.199 is less flashy, but it makes the background workflow more usable. The changelog lists several fixes where partial work and errors should now reach the lead agent: streaming responses interrupted after partial output are kept with an incomplete-response notice, subagents cut off by a rate limit or server error return their partial work, and subagents that hit API errors should no longer report success.

That is the kind of detail that decides whether an agent workflow becomes daily practice or stays a demo. A team needs to know whether work is complete, waiting for input, failed, or left a partial result that someone must read. Otherwise, background agents are just more black boxes.

2.1.199 also fixes practical operations problems: the Linux daemon could kill itself and running agents after a corrupted worker record, claude stop could be undone by a competing respawn, the agent view could briefly flap between Working and Idle, and low-memory machines should now get a clearer explanation.

Source: GitHub release v2.1.199

Source: npm registry for @anthropic-ai/claude-code

What Nordic teams can do with the signal

Do not treat background agents as "more automation" first. Treat them as a work queue. Every job needs a name, an owner, a status, a boundary for what the agent may do on its own, and a review point before changes move forward.

For a development team, the first routine can be simple:

• Needs input means a person must answer before the agent continues.
• Completed means someone reads the diff, test result, and any draft PR.
• Failed means partial work and the error message are saved, not thrown away.
• Worktree jobs may create draft PRs, but merge requires human approval.

When you connect the agent to real repositories, issue systems, or internal tools, keep the controls practical: scoped API keys, secrets in environment variables or a secret manager, redacted output in logs, clear approval gates, and audit logs for agent runs. That makes the integration brave enough to use and clear enough to review.

Try this prompt this week

Human step: use an environment where Claude Code 2.1.199 is available, or gather your current claude agents routine, worktree rules, PR routine, and recent background-job failures. Handle installation, updates, and version checks outside the prompt.

Read our latest Claude Code agent jobs, worktree rules, and PR routine.
Compare them with 2.1.198-2.1.199: background by default, Notification hooks, draft PRs, and errors reported to the lead.
Choose one work queue we should test first and write a short run card.
Show what the agent may do alone, what needs approval, and how we see completed, needs input, or failed.
End with two open questions.

Good output should include:

• a concrete work queue, not a general AI policy
• a clear status model for agent jobs
• a boundary between the agent's draft PR and the human merge decision
• one log line for partial work, errors, and notifications

Hammer angle

This is a Tool Forge question. Claude Code becomes more useful when background work can leave the chat and become a reviewable queue. Build that queue around real tools, but bring permissions, secrets, approvals, and logs with it from the start.