Agent View hard-disabled on AWS Bedrock / Vertex / Foundry backends

Status Fixed / completed
Reported on v2.1.139
Maintainer reply ✓ Yes — bogini
Activity 5 comments · opened May 12, 2026 · closed May 13, 2026
💡 Likely answer: A maintainer (bogini, collaborator) responded on this thread — see the highlighted reply below.

Summary

Agent View (claude agents, /background, /bg, left-arrow detach) is unavailable in v2.1.139 for any user on a third-party provider backend, even when no disableAgentView setting is present and CLAUDE_CODE_DISABLE_AGENT_VIEW is unset.

The docs at https://code.claude.com/docs/en/agent-view do not mention this restriction — they state only that disableAgentView is the off-switch and that v2.1.139+ is required.

Reproduction

  1. Set CLAUDE_CODE_USE_BEDROCK=1 (or CLAUDE_CODE_USE_VERTEX=1, etc.) and configure provider credentials
  2. Install Claude Code 2.1.139
  3. Run claude agents → returns the static built-in agent definition list, not the tabbed running/blocked/done view
  4. Inside an interactive session, /bg and /background both return No commands match

Root cause

In the compiled binary, the Agent View enable-check resolves to:

function DWH(){
  return SH(process.env.CLAUDE_CODE_DISABLE_AGENT_VIEW)
      || vS()?.settings.disableAgentView === true
      || yk1();
}

function yk1(){
  return SH(process.env.CLAUDE_CODE_USE_BEDROCK)
      || SH(process.env.CLAUDE_CODE_USE_VERTEX)
      || SH(process.env.CLAUDE_CODE_USE_FOUNDRY)
      || SH(process.env.CLAUDE_CODE_USE_ANTHROPIC_AWS)
      || SH(process.env.CLAUDE_CODE_USE_MANTLE)
      || A\$() !== null;
}

yk1() returning true forces Agent View off regardless of user/admin settings.

Asks

  1. Document the third-party-provider exclusion on the Agent View page so users on Bedrock/Vertex don't waste time debugging.
  2. If the gate exists because of dependencies on Anthropic-operated infra (push notification preferences endpoint, etc.), please clarify what's blocking — the daemon itself looks provider-agnostic.
  3. Either lift the gate for Bedrock/Vertex or expose an opt-in env var for users willing to live without the Anthropic-only side features.

Environment

  • Claude Code: 2.1.139 (macOS arm64, Darwin 24.5.0)
  • Backend: AWS Bedrock (CLAUDE_CODE_USE_BEDROCK=1, eu-west-1)
  • No disableAgentView set in user, project, or managed settings
  • No CLAUDE_CODE_DISABLE_AGENT_VIEW env var

View original on GitHub ↗

5 Comments

pengchengneo · 3 months ago

Same issue here. I'm using a custom ANTHROPIC_BASE_URL (API proxy), not Bedrock/Vertex/Foundry. Agent View is silently disabled — claude agents only lists agent configurations, key does nothing, and /bg works but the TUI never appears. The daemon and background sessions work fine, so the gate seems unnecessary for proxy users.

Environment:

  • Claude Code: 2.1.139 (macOS arm64, Darwin 25.2.0)
  • Backend: Anthropic API via custom ANTHROPIC_BASE_URL
  • No disableAgentView set, no CLAUDE_CODE_DISABLE_AGENT_VIEW env var
bogini collaborator · 3 months ago

Thanks for reporting. This was a feature-flag delivery issue — claude agents was gated on a GrowthBook flag whose cache could be stale or unreachable depending on platform/network. We've removed the gate entirely; claude agents now opens the dashboard unconditionally (including on Bedrock/Vertex/Foundry).

Ships in v2.1.141 (tomorrow).

np2446 · 3 months ago
Thanks for reporting. This was a feature-flag delivery issue — claude agents was gated on a GrowthBook flag whose cache could be stale or unreachable depending on platform/network. We've removed the gate entirely; claude agents now opens the dashboard unconditionally (including on Bedrock/Vertex/Foundry). Ships in v2.1.141 (tomorrow).

is this still getting shipped today?

claude[bot] contributor · 3 months ago

This issue was fixed as of version 2.1.141.

github-actions[bot] · 1 month ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.