openclaw - 💡(How to fix) Fix PI harness ignores `cliBackends` configuration, splitting subagent execution and chat path onto different transports for the same OAuth credential [1 participants]

Affected version

OpenClaw 2026.4.24 (build cbcfdf6).

Summary

Anthropic's Claude CLI binary is exempt from the "third-party apps now draw from your extra usage, not your plan limits" filter, but Anthropic's direct API treats OAuth-credential-as-bearer requests as "third-party app" usage. OpenClaw chat goes through cli-backend (subprocess invocation of the claude binary) which gets the exemption. OpenClaw subagent execution falls through to the PI harness, which dispatches via direct API on the same OAuth token — and bills against extra-usage credits.

The two paths bifurcate on the same credential, with very different cost properties.

Why it matters

For users on the sanctioned claude-cli cliBackend setup (Max plan + OAuth, no API key):

The asymmetry is invisible to the user until they exercise sessions_spawn. The first time they do, they discover their Path B subagents bill differently than their chat does — using the same credential.

Architectural cause

The PI harness (built-in default) dispatches model calls through provider plugins (e.g., anthropic) which use the credential to make HTTP calls against api.anthropic.com. cliBackends is a separate abstraction: when explicitly invoked (e.g., by webchat's chat code), it spawns the claude binary as a subprocess. PI doesn't consult cliBackends.

So a config that defines cliBackends.claude-cli AND uses PI harness will use the cliBackend for chat (because chat calls cliBackend directly) but the direct-API path for everything else (because PI doesn't know about cliBackends).

What "consult cliBackends" might look like

When PI's anthropic provider dispatches and detects:

1. The current auth.profiles.<provider-key> is in mode: "oauth" AND provider: "claude-cli" (or equivalent CLI-backed credential type), AND
2. agents.defaults.cliBackends.<backend-id> is configured for the routed model's provider,

then route the dispatch through the cliBackend (spawn the binary) instead of the direct-API path. That would make subagent execution match chat's billing characteristics for users who've explicitly configured the cliBackend.

A coarser version: a config flag like agents.defaults.embeddedHarness.preferCliBackend: true that explicitly opts the PI harness into cliBackend dispatch when available.

Adjacent

• #33587 — Codex embedded runner should auto-route through CLI backend when configured (same architectural shape, Codex side)
• #63316 — openclaw-claude-proxy mode: CLI delegation & community proxy support (maintainer-tracked meta-issue on post-Anthropic-policy routing)
• #16365 — Extend Pro/Max Subscription Auth to OpenClaw (canonical billing-policy thread)

Empirical impact (one user's data)

After landing local patches for the two related bugs (prepareContextEngineSubagentSpawn init + resolvePinnedAgentHarnessPolicy fallback), a successful end-to-end mcp__openclaw__sessions_spawn test (verified by model.completed event with non-zero lastCallUsage.total in the trajectory file) was achieved only after manually enabling extra-billing on the user's Claude account. Without extra-billing enabled, the same patches let the spawn proceed to the model-call step but fail with the "Third-party apps now draw from your extra usage" 400.

The architectural fix (PI consults cliBackends) would let this user, and any user on the same Max-plan-only setup, run subagents end-to-end without paying extra-usage — matching the behavior they get from chat today.

Mitigation users can apply locally

• Add a real Anthropic API key as a second auth.profiles entry so PI failover has a non-OAuth credential to land on
• Or constrain subagents to non-Anthropic providers (MinMax, OpenAI, Ollama, etc.) which don't trigger the third-party-apps filter

Neither is a substitute for fixing the asymmetry at source.