Claude Code v2.1.139: Agent View, Goal Command, and Hook Upgrades That Change How Builders Orchestrate Sessions

Claude Code has been evolving rapidly from a terminal-based coding assistant into a platform for managing multiple autonomous coding sessions. Version 2.1.139 pushes that trajectory forward with three categories of changes: session orchestration (Agent View and /goal), automation control (hook exec form, continueOnBlock, plugin token cost), and infrastructure reliability (MCP project directory, subagent tracing headers, memory growth cap).

For developers running Claude Code in multi-repo or CI environments, these changes address concrete pain points: not knowing which sessions are active, not being able to set autonomous completion conditions, and not having fine-grained control over how external hooks interact with the coding loop. The bug-fix batch also resolves a deadlock in credential handling and caps HTTP/SSE response bodies to prevent unbounded memory growth.

The Agent View command (claude agents) is tagged as a Research Preview, which means the interface and behavior may change. What it provides today is a single list of every Claude Code session across states: running, blocked on user input, or completed. According to the release notes, this covers interactive sessions, -p (print) mode invocations, and Remote Control sessions.

For developers who use Claude Code across multiple repositories or in CI pipelines, this is a visibility upgrade. Previously, managing multiple Claude Code sessions required manual tracking or external tooling. Agent View consolidates session state into one interface, reducing the risk of orphaned sessions or forgotten long-running tasks.

The release notes link to official documentation at code.claude.com/docs/en/agent-view for further details. Because this is a research preview, builders should expect iteration and not yet rely on the exact interface shape for automation scripts.

The /goal command introduces a structured way to set a completion condition for Claude Code. Once a goal is set, Claude continues working across multiple turns until the condition is met. The release notes specify that /goal works in interactive mode, -p (print) mode, and Remote Control, and that it shows a live overlay panel with elapsed time, turn count, and token usage.

This is distinct from asking Claude to complete a task in a single prompt. The /goal command explicitly frames the work as multi-turn and autonomous, with the overlay providing real-time observability into how many resources the agent is consuming. For CI or batch processing workflows, this transforms Claude Code from a request-response tool into a goal-driven agent that terminates on its own when the condition is satisfied.

The live elapsed/turns/tokens overlay is particularly relevant for cost management. Builders running Claude Code in automated pipelines can monitor resource consumption without interrupting the agent loop.

Claude Code hooks allow external scripts to intercept and respond to tool-use events. Version 2.1.139 adds two significant capabilities to the hook system.

First, the exec form (args: string[]) spawns commands directly without wrapping them in a shell. This eliminates quoting issues with path placeholders, which have been a source of friction when hooks reference files with spaces or special characters in their paths. For automation builders, this means more reliable hook execution across different operating systems and file-system layouts.

Second, the continueOnBlock config option for PostToolUse hooks changes how rejections are handled. Previously, when a PostToolUse hook rejected an action, the turn would stop. With continueOnBlock set to true, the hook rejection reason is fed back to Claude, and the turn continues. This allows Claude to reason about why a hook rejected an action and attempt an alternative approach, rather than simply failing.

Both changes are aimed at builders who integrate Claude Code into larger automation pipelines where hooks enforce security policies, validate outputs, or gate deployments.

The release makes two MCP (Model Context Protocol) improvements. MCP stdio servers now receive CLAUDE_PROJECT_DIR in their environment, matching the behavior of hooks. This means plugin configurations can reference ${CLAUDE_PROJECT_DIR} in commands, enabling path-relative server configurations that work across different project directories without manual adjustment.

The /mcp reconnect command now picks up .mcp.json edits without a full restart, and shows the HTTP status and URL when reconnection fails. This reduces friction during development when MCP server configurations change frequently.

Plugin token transparency also improves: claude plugin details <name> now shows a plugin component inventory and projected per-session token cost. The /context all command now accounts for the model tokenizer when estimating per-skill token usage, showing rounded values rather than raw estimates. These changes help builders understand the token budget impact of each plugin and skill before committing to a session configuration.

Two changes affect how Claude Code behaves in multi-agent and enterprise contexts. API requests from subagents now carry x-claude-code-agent-id and x-claude-code-parent-agent-id headers, and claude_code.llm_request OpenTelemetry spans include agent_id and parent_agent_id attributes. This enables observability tooling to trace request lineage across parent-child agent relationships, which is essential for debugging multi-agent workflows and attributing costs to specific agents.

On the feature isolation side, Remote Control, /schedule, claude.ai MCP connectors, and notification preferences are now automatically disabled when ANTHROPIC_API_KEY, apiKeyHelper, or ANTHROPIC_AUTH_TOKEN is set, even if a claude.ai login also exists. This prevents feature conflicts in environments where API-key authentication is the primary access method. The release notes note that unsetting the API key restores these features.

The release includes a substantial batch of bug fixes. Several are relevant for builders running Claude Code in production or CI environments:

A deadlock involving expired credentials and the forceRemoteSettingsRefresh policy setting could block claude auth login, logout, and status with no way to recover. This is now fixed.

Unbounded memory growth when an HTTP/SSE MCP server streams non-protocol data is now capped at a 16 MB limit per SSE frame. This prevents resource exhaustion from misbehaving MCP servers.

The autoAllowBashIfSandboxed setting now correctly auto-approves commands containing shell expansions like $VAR and $(cmd), which previously required manual approval despite being in sandboxed mode.

Skill permission rules using the wildcard form Skill(name *) now work as prefix matches, matching the existing Bash(ls *) behavior. Previously, wildcard skill permission rules were incorrectly flagged as unparseable.

Additional fixes address settings hot-reload for symlinked configuration files, MCP resource cleanup for disconnected servers, scroll speed consistency across terminal emulators, and visual rendering issues for CJK characters and emoji in border elements.

Agent View is labeled Research Preview, which means the interface, command name, and behavior may change in future releases. Builders should not yet hard-code Agent View output parsing into automation scripts.

The /goal command does not specify how complex or ambiguous conditions are evaluated. Whether Claude can reliably determine that a goal like "all tests pass and the PR is ready for review" is met remains to be seen in practice.

The 16 MB SSE frame cap is a safety measure, but whether it is the right threshold for all MCP server configurations is unclear. Heavily streaming servers may hit the cap frequently.

The continueOnBlock behavior could interact unpredictably with complex hook chains. When a PostToolUse hook rejects an action and Claude retries with an alternative approach, the second attempt may trigger a different hook with its own rejection. Teams with layered hook policies should test the interaction carefully.

API key feature isolation disables Remote Control and /schedule when an API key is present. Teams that use both API-key and claude.ai authentication in the same environment will need to decide which access mode to prioritize.

If you are running Claude Code in multi-session or CI environments, upgrade to v2.1.139 for the memory growth cap and deadlock fix alone. These are reliability improvements that matter in automated contexts. Then explore Agent View for session visibility and /goal for autonomous task completion, treating both as research-preview capabilities that may evolve.

For teams using hooks to enforce security or compliance policies, the exec form and continueOnBlock options are production-ready improvements that reduce quoting friction and enable more sophisticated rejection handling. Start by migrating existing shell-form hooks to exec form and evaluating continueOnBlock for PostToolUse hooks that currently terminate the turn on rejection.

This analysis is based on the following primary source, accessed on 2026-05-11:

1. "Release v2.1.139" by Anthropic, published on GitHub at https://github.com/anthropics/claude-code/releases/tag/v2.1.139

All feature descriptions, command names, configuration options, and bug-fix details are cited directly from the official release notes. No hands-on testing was performed by SignalForges. No claims about performance, reliability, or user experience beyond what the release notes state are made. Feature descriptions tagged as Research Preview should be treated as subject to change.