v1.0.79: SDK crashes with dangerouslyAllowBrowser error on self-hosted runners

[cthorpe-CLASS]

Description

After updating from v1.0.72 to v1.0.79, the Claude Code Action crashes immediately during initialization with the Anthropic SDK's dangerouslyAllowBrowser error. This happens on all self-hosted runners (tested on 3 separate runners). Rolling back to v1.0.72 (SDK 0.2.76) resolves the issue.

Error

SDK execution error: 53 | you can set the \`dangerouslyAllowBrowser\` option to \`true\`, e.g.,
54 | 
55 | new Anthropic({ apiKey, dangerouslyAllowBrowser: true });

error: Claude Code process exited with code 1

Environment

• Self-hosted runners on Ubuntu 24.04 (x64)
• Bun 1.3.6 (installed via oven-sh/setup-bun)
• Node 22 (installed via actions/setup-node)
• Runner version: 2.333.0
• Auth method: OAuth token (claude_code_oauth_token)

Reproduction

1. Pin to v1.0.79 SHA 3ac52d0da9f8ec9ca7b4dc23bb477e36ef9c77a9
2. Trigger via @claude comment on an issue
3. Action crashes during SDK initialization, before any Claude work begins

Working vs Broken

Version	SDK	Result
v1.0.72 (cd77b50)	0.2.76	Works — successful audit runs daily
v1.0.79 (3ac52d0)	0.2.84	Crashes — dangerouslyAllowBrowser

Root Cause Hypothesis

The Anthropic JS SDK's browser environment detection was tightened in a version between 0.2.76 and 0.2.84. Since the action's entrypoint runs via bun run, and Bun exposes browser-like globals (e.g., window, navigator), the SDK incorrectly identifies the runtime as a browser and refuses to run.

Workaround

Pinned to v1.0.72 (cd77b50d2b0808657f8e6774085c8bf54484351c). This blocks us from receiving security and feature updates.

[cthorpe-CLASS]

Update: Rolling back to v1.0.72 does NOT fix the issue. The same AJV schema validation crash now occurs on v1.0.72, which was working fine yesterday (2026-03-25, run 23535574669 succeeded on class-ci-3).

This means the root cause is an Anthropic API-side change, not a SDK version regression. The API is returning a response that fails JSON schema validation in all SDK versions (tested 0.2.76 and 0.2.84).

Timeline

• 2026-03-25 10:07 UTC — v1.0.72 (SDK 0.2.76) succeeds on class-ci-3
• 2026-03-26 10:05 UTC — v1.0.72 (SDK 0.2.76) fails with AJV depsCount error on class-ci-2
• 2026-03-26 ~20:35 UTC — v1.0.79 (SDK 0.2.84) fails with dangerouslyAllowBrowser error on class-ci-3
• 2026-03-26 22:13 UTC — v1.0.72 (SDK 0.2.76) again fails with AJV depsCount error on class-ci-1

All three self-hosted runners exhibit the same behavior. The crash occurs immediately after SDK config is output, before any Claude work begins.

[cthorpe-CLASS]

Resolved in v1.0.82 (commit 88c168b, Claude Code 2.1.87, Agent SDK 0.2.87).

Updated our workflows from v1.0.79 → v1.0.82 and confirmed the @claude trigger is working again on self-hosted runners.

Closing as resolved. Thanks!

[cthorpe-CLASS]

Reopening — v1.0.82 does not fix this. Same crash on self-hosted runner.

The dangerouslyAllowBrowser text in the error output is a red herring — it's minified source code being printed. The actual error is Could not resolve authentication from validateHeaders() in the Anthropic SDK.

The OAuth token is set (CLAUDE_CODE_OAUTH_TOKEN: *** visible in logs), but Claude Code exits with code 1 immediately after SDK initialization.

SDK execution error: ...throw Error('Could not resolve authentication')...
error: Claude Code process exited with code 1

Tested on v1.0.79, v1.0.82 — same result. Token was working as recently as 2026-03-25.

[cthorpe-CLASS]

Reopening again — this is NOT a token issue. Tested with a freshly generated claude setup-token OAuth token (sk-ant-oat01-*). Same crash.

Root cause narrowed: The Agent SDK spawns Claude Code, passes SDK options, then Claude Code crashes ~500ms later during initialization. The minified state dump shows oauthTokenFromFd:void 0, apiKeyFromFd:void 0 — suggesting the token is not being passed to the child process correctly.

Timeline of each run:

T+0.0s: SDK prints options (allowedTools, mcp-config, etc.)
T+0.5s: "SDK execution error: ...throw Error('Could not resolve authentication')"
T+0.5s: "error: Claude Code process exited with code 1"

Claude Code never makes an API call — it crashes during initialization when validateHeaders() finds neither x-api-key nor authorization header available.

Tested: v1.0.79 and v1.0.82, both with claude_code_oauth_token. Self-hosted runner, show_full_output: true enabled. The native claude --print command works fine with the same user's stored credentials on the same machine.