claude-code-action: SDK session returns is_error:true with zero turns/tool calls (subtype:success, 0 cost) — reproduces across v1.0.160 to v1.0.201, with and without --json-schema

[piro-anthony-stack]

Summary

claude-code-action consistently fails since ~2026-08-23 20:47 UTC (still failing as of 2026-08-24): the Claude Agent SDK session returns a result event with is_error: true, num_turns: 1, duration_ms in the 200-280ms range, and total_cost_usd: 0 — with no assistant message, no tool call, and no actual work performed — despite subtype: "success" on the same result object. Reproduced across 3 action versions and 2 models, so this doesn't look like a version-specific regression on our side.

Environment

• Action versions tested: v1.0.160 (2026-06-29), v1.0.199 (2026-08-21), v1.0.201 (2026-08-23) — all reproduce identically.
• Models tested: claude-sonnet-4-6 (production workflow) and claude-haiku-4-5 (isolated repro below) — both affected.
• Auth: anthropic_api_key input (direct API key, not OAuth/Bedrock/Vertex).
• Trigger: both pull_request and manual workflow_dispatch reproduce it.

Minimal repro

- uses: anthropics/claude-code-action@v1.0.160
  id: probe
  continue-on-error: true
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    claude_args: |
      --max-turns 3
      --model claude-haiku-4-5
      --allowedTools "Read"
    prompt: |
      Read README.md, then respond with "OK".

Result event captured from the run log:

{"type": "system", "subtype": "init", "message": "Claude Code initialized", "model": "claude-haiku-4-5"}
{"type": "result", "subtype": "success", "is_error": true, "duration_ms": 220, "num_turns": 1, "total_cost_usd": 0, "permission_denials_count": 0}

No event in between — no assistant turn, no Read tool call, nothing. The SDK goes straight from init to an is_error: true result in ~220ms.

With --json-schema (our production config on gardien.yml)

Adding --json-schema '{"type":"object","properties":{"verdict":{"type":"string","enum":["A","B","C"]}},"required":["verdict"]}' to the same config turns this into a hard action failure:

##[error]--json-schema was provided but Claude did not return structured_output. Result subtype: success
##[error]Action failed with error: --json-schema was provided but Claude did not return structured_output. Result subtype: success

Also worth noting: the action logs Set session_id: <uuid> internally right before this error, but steps.<id>.outputs.session_id is empty afterward — the session_id output isn't populated on this failure path, even though a session_id clearly exists internally.

Impact on our side

We use claude-code-action for 4 automated review/monitoring workflows (PR review bot, an issue-triage bot, a staging/main drift auditor, and an hourly production monitor). All 4 depend on --json-schema + steps.*.outputs.structured_output to turn a review verdict into a pass/fail CI check (rather than parsing free-text comments, which we'd previously found fragile). Since this started, our PR-review bot fails on every single PR with zero real review performed, and we've had to bypass required-status-check protection to keep merging. We initially suspected a version regression (the floating @v1 tag had just moved to a new release with an Agent SDK bump) and pinned to progressively older versions, but the failure reproduces identically all the way back to v1.0.160 (2026-06-29) and with --json-schema removed entirely — so it doesn't look like something we can route around with a version pin.

Question

Is this a known incident (API-side or Agent SDK-side) rather than an action bug? Happy to provide full run logs / workflow files if useful.

[piro-anthony-stack]

Update — a variant of this observed today on a different PR, using the same --json-schema config as the original report (still pinned to v1.0.199).

Run: https://github.com/piro-anthony-stack/monequipe.ia/actions/runs/32726720097
Comment posted by that run: https://github.com/piro-anthony-stack/monequipe.ia/pull/171#issuecomment-5395165526

This run took 5m32s (not the near-instant ~220-280ms failure from the original report) and did post a real, substantive review comment on the PR — readable text addressing the actual diff, referencing specific files/lines. So the underlying Claude session clearly executed the review task correctly.

Despite that, our downstream step read empty values for both outputs:

STRUCTURED_OUTPUT:
REVIEW_SESSION_ID:
REVIEW_OUTCOME: failure

Same as the original report, --json-schema was provided but no structured_output was captured — but this time a full review clearly ran and successfully posted its result via gh pr comment. The only failure is in the structured-output/session_id extraction after the fact, not in the session itself.

This is a different signal from the original report (there, duration_ms: 220-280, is_error: true, zero tool calls, zero assistant turns — nothing happened at all). Here the session did real multi-turn work and produced a valid result; only steps.<id>.outputs.structured_output and .session_id failed to populate. Might point toward an issue in how/when those outputs get set on this failure path, rather than a session-level problem — flagging in case it's a useful data point, no further speculation on the cause from our side.

[farmer-data]

The two signals in this thread look like different failures, and only one is still live.

Signal 1 — the 220ms is_error:true / num_turns:1 / cost:0 init crash — appears resolved. A downstream consumer bumping v1.0.193 -> v1.0.205 reported it cleared (POWERFULMOVES/PMOVES.AI@8035275), consistent with the Claude Code 2.1.241–2.1.245 bumps in that range rather than anything in the action itself.

Signal 2 — the Aug 24 follow-up, where a 5m32s run did real work and posted a genuine review but returned empty session_id and structured_output — is still present on main.

The session id is read from the system.init message and logged at base-action/src/run-claude-sdk.ts:233, but it is only published as an output by the callers (base-action/src/index.ts:67, src/entrypoints/run.ts:310), after runClaude returns. Every failure path below the extraction throws rather than returns — the is_error check, the maxTurns check, and the --json-schema structured-output check at line 274 — so the caller's setOutput block is skipped entirely and the catch rescues only execution_file via setExecutionFileOutputIfPresent().

That matches the original report exactly:

the action logs Set session_id: <uuid> internally right before this error, but steps.<id>.outputs.session_id is empty afterward — the session_id output isn't populated on this failure path, even though a session_id clearly exists internally.

base-action/src/run-claude-sdk.ts is unchanged from v1.0.193 through current main apart from #1608's model-limits logging, which doesn't touch this path — so no version bump has addressed signal 2.

I have a small patch that publishes session_id where it is discovered, giving it the same error-path guarantee execution_file already has. Opening it as a PR shortly. It would not close this issue: the missing structured_output is the separate, still-open question, and there is nothing to publish for it on that path because the SDK never returned it — which is why the code throws in the first place.

[johump]

Additional data point with an unusually clean elimination table. Repo: private, wp-review + claude-code-review workflows, claude_code_oauth_token auth. Failures began 2026-08-29T03:38Z sharp and reproduce ~100% since (a dozen runs): result JSON is exactly {subtype: success, is_error: true, num_turns: 1, total_cost_usd: 0, modelUsage: {}} ~1.9s after the CLI init line, with NO error text even under ACTIONS_STEP_DEBUG. Everything else is proven identical across the cliff: same action SHA (a874e9e), same Claude CLI version on both sides (2.1.251, native build — a success at 03:18Z and every failure since ran the same version), same runner image family (successes and failures both on 20260823.283.1), token re-minted mid-window with no change, and a lean reopened PR fails identically to a comment-heavy one, so prompt size is excluded. From our seat this looks server-side or account-state-triggered rather than version-correlated. Happy to provide run IDs privately.