On April 4, 2026, Anthropic stopped letting third-party tools run on Claude Pro or Max subscription limits. If you were using OpenClaw, NanoClaw or a similar framework on your subscription, you suddenly needed extra usage or an API key.
My multi-agent orchestration system kept running. Not because I found a workaround, but because it never used OAuth in the first place. It spawns the official claude CLI and lets the binary handle its own authentication. No tokens, no gateway, no SDK calls.
This page is the complete answer to "what is the best OpenClaw alternative": what Anthropic changed, why OpenClaw was fragile long before that, twelve alternatives compared by auth model, and the CLI subprocess pattern with the four invocation variants I run in production. It started as a three-part series in April 2026. I merged it into one page and updated it in September 2026.
What Anthropic Actually Changed
Here's how Anthropic's documentation put it in February 2026, as reported by The Register:
"Using OAuth tokens obtained through Claude Free, Pro, or Max accounts in any other product, tool, or service, including the Agent SDK, is not permitted and constitutes a violation of the Consumer Terms of Service."
The Claude Code legal docs still state: "Anthropic does not permit third-party developers to offer Claude.ai login into their own applications, or to route requests through Free, Pro, or Max plan credentials on behalf of their users."
Anthropic's stated reason was load: third-party harnesses put "an outsized strain on our systems". In practice it was token arbitrage. A $200/month Max subscription was generating API-equivalent workloads far beyond what it was priced for.
| Date | Event |
|---|---|
| November 2025 | Peter Steinberger releases Clawdbot, a personal AI assistant |
| January 9, 2026 | Anthropic starts rejecting subscription OAuth tokens from tools that spoof the Claude Code client. OpenCode is the first high-profile casualty |
| January 30, 2026 | Renamed to OpenClaw (via Moltbot). Growth explodes |
| February 2026 | First CVEs, including CVE-2026-25253: one-click RCE via a leaked gateway token. Later that month: ClawJacked, a separate WebSocket hijack of local instances |
| February 2026 | ClawHavoc: supply chain attack on the ClawHub skill marketplace |
| February 14, 2026 | Steinberger announces his move to OpenAI; the project moves to a foundation |
| February 20, 2026 | Anthropic updates its documentation: OAuth for third-party tools explicitly banned |
| April 4, 2026 | Enforcement via billing: third-party tools draw from extra usage instead of subscription limits. Subscriptions keep covering Claude.ai, Claude Code and Cowork |
| May 13, 2026 | Anthropic announces separate Agent SDK credits for programmatic and third-party use |
| June 15, 2026 | Anthropic pauses that change on the day it was due. claude -p, the Agent SDK and third-party apps keep drawing from subscription limits |
The Security Record: The Bigger Problem
The OAuth ban didn't kill OpenClaw. Its security record was the bigger issue long before Anthropic acted.
A keyword search for OpenClaw in the National Vulnerability Database returned about 200 results in April 2026 and close to 600 by September. Not every hit is a separate OpenClaw CVE, but the direction is clear. Some of the named ones:
| CVE | Severity | Type |
|---|---|---|
| CVE-2026-25253 | CVSS 8.8 | One-click RCE via auth token exfiltration (gatewayUrl) |
| CVE-2026-24763 | High | Command Injection via Docker PATH |
| CVE-2026-25157 | High | OS Command Injection via SSH |
| CVE-2026-25475 | CVSS 6.5 | Path traversal, arbitrary file read |
| CVE-2026-26322 | CVSS 7.6 | Server-side request forgery via gatewayUrl |
ClawHub had no mandatory code review for submitted skills. Attackers used that to distribute the Atomic macOS Stealer and Windows infostealers, documented by several security firms. SecurityScorecard found more than 40,000 internet-exposed instances, 63% of them vulnerable.
That is what happens when a personal assistant designed for localhost becomes internet-facing infrastructure without the security architecture to match.
Why the OAuth Ban Was Architecturally Predictable
OpenClaw is a harness model: it wraps an LLM provider's API with the user's credentials. The user logs in, the tool captures the OAuth token and routes every request through it. That creates three structural problems:
- Credential accumulation. Every key and token lives in the tool's config, often in plaintext. One compromised instance leaks everything.
- Trust boundary collapse. The process that routes your WhatsApp messages also holds your Claude credentials.
- Platform dependency. The whole tool depends on one provider's willingness to let you use its auth tokens. When that provider says no, the tool is dead.
I've called this the difference between routing and orchestration. The CLI subprocess pattern avoids all three problems: no stored credentials, no shared trust boundary, no dependency on someone else's auth.
OpenClaw Alternatives Compared
I analyzed twelve frameworks in four categories on one question first: how does it handle auth? Star counts are from April 2026.
AI coding assistants
| Framework | Auth model | Affected by the ban? | Governance |
|---|---|---|---|
| Cursor | Own infrastructure + subscription | No | None |
| Devin Desktop, formerly Windsurf | Own infrastructure + subscription | No | None |
| Aider | Your own API keys | No | Git-based audit trail |
| Continue.dev | Your own API keys + local models | No | None |
| Codex CLI | OpenAI account | No, different provider | Sandboxed execution |
Multi-agent frameworks
| Framework | Auth model | Affected? | Multi-agent | Governance |
|---|---|---|---|---|
| CrewAI | API keys | No | Role-based crews | Basic logging |
| AutoGen (maintenance mode, succeeded by Microsoft Agent Framework) | API keys | No | Conversation patterns | Session state |
| LangGraph | API keys | No | DAG state machines | Checkpoints |
| OpenHands | API keys | No | Event-sourced | Docker isolation |
| OpenAI Agents SDK | OpenAI API key | No | Minimal primitives | Guardrails |
Workflow platforms: n8n with AI nodes, Dify and Agno all use API keys per node or app. None were affected.
CLI subprocess orchestration: VNX Orchestration, my own system. It handles no credentials at all. It spawns official CLI binaries (claude, codex, gemini) and lets them authenticate themselves.
The pattern across all four: every serious framework uses direct API keys. The subscription-OAuth model belonged to a small group of harnesses, OpenClaw and OpenCode above all. The framework you pick matters far less than the auth model underneath it.
Three Architectural Patterns That Survive
1. Direct API keys. You pay per token and manage your own keys. Used by CrewAI, LangGraph, AutoGen, Aider and almost everything else. Simple and well supported, but costs scale with usage, and autonomous agents can surprise you. Best for teams with predictable workloads and proper secrets management.
2. CLI subprocess. You spawn the official binary and it authenticates with your own logged-in session. Zero credential handling and immune to auth policy changes. The trade-offs: you are coupled to the CLI's interface, each call has startup overhead, and it is single-user by design, because the CLI authenticates as you. Best for solo developers and small teams orchestrating their own work.
3. Platform-native. You use what the provider ships: Agent Teams, MCP servers, Projects. No compliance risk and no infrastructure, but no custom governance layer and full vendor lock-in.
The CLI Subprocess Pattern in Four Variants
The principle fits in one line: spawn the official CLI binary, let it handle auth, keep your orchestration layer clean.
import subprocess
def ask_claude(prompt: str) -> str:
result = subprocess.run(
["claude", "--print", "--output-format", "text"],
input=prompt,
capture_output=True,
text=True
)
return result.stdoutThat is the entire integration. No SDK import, no token management. It works the same for Codex CLI and Gemini CLI. In production I run four variants of it.
Variant A: interactive terminal via tmux
Claude runs in an interactive session that tmux manages. The orchestrator types into the pane and reads the pane buffer.
tmux send-keys -t "$T0" "claude --model $t0_model $t0_flags" C-m
tmux capture-pane -t "$T1" -p -S -50 # read the last 50 linesUse it when the task needs Claude's full interactive tool set. The gotchas: sessions can die with in-flight work (checkpoint state externally), long output gets truncated (history-limit), and send-keys does not tell you whether a command succeeded.
Variant B: headless subprocess
No terminal UI. A prompt goes in, text or JSON comes out.
def ask_claude_json(prompt: str, model: str = "sonnet") -> dict:
result = subprocess.run(
["claude", "-p", "--output-format", "json", "--model", model, "--max-turns", "1"],
input=prompt, capture_output=True, text=True, timeout=300
)
if result.returncode != 0:
return {"error": result.stderr}
try:
return json.loads(result.stdout)
except json.JSONDecodeError:
return {"error": "Invalid JSON", "raw": result.stdout}Use --output-format stream-json with subprocess.Popen for real-time events, and --resume <session_id> to continue a session. Every call has a few seconds of startup overhead. Check the return code, not stderr, because stderr also carries warnings.
Variant C: one-shot analysis
A specialised form of B: send code or a diff, get a structured verdict back. Claude sometimes wraps JSON in a markdown fence even when you ask for JSON, so always keep a fallback parser that strips the fence.
Variant D: provider command builder
Put every CLI invocation behind one function. When flags change, you update one file. When you want Gemini instead of Claude for a task, you change a field. The orchestration logic never knows which model runs.
def build_command(tc: TerminalConfig) -> str:
if tc.provider == "claude":
tools = f" --allowedTools {','.join(tc.allowed_tools)}" if tc.allowed_tools else ""
return f"claude --model {tc.model}{tools}"
if tc.provider == "gemini":
return f"gemini --model {tc.model}"
if tc.provider == "codex":
return f"codex --model {tc.model}"
raise ValueError(f"Unknown provider: {tc.provider}")Early versions of my system used --dangerously-skip-permissions here. I removed it from my stack. Each worker now gets an explicit --allowedTools allowlist with ambient MCP off: exactly the tools its task needs, nothing more.
The June 2026 detour: which variant for which lane
When I first wrote this, the direction looked clear: move everything from tmux to headless claude -p. Then Anthropic announced that from June 15, 2026, claude -p and Agent SDK usage would move to a separate monthly credit instead of subscription limits.
I took that seriously and built a hedge: an ephemeral tmux-spawn lane. A fresh interactive window per dispatch, so Claude workers would stay on the subscription whatever happened to headless billing.
Anthropic paused the change on the day itself. claude -p still draws from the subscription, so I went back to headless as the default. The tmux-spawn lane is still there, idle, ready if the announcement ever comes back.
So the current split is:
- Claude workers: variant B, headless. Scriptable, no terminal to babysit.
- Codex, Gemini, Kimi and DeepSeek: variant B as well. Pure headless subprocess.
- Variant A in ephemeral mode as a standby lane, for the day subscription billing for headless changes after all.
- Variant D everywhere, so switching lanes is a config change, not a rewrite.
Building that standby lane surfaced one bug worth knowing about. My first real task through it sat idle: the instruction arrived at the prompt but was never submitted. The readiness check still waited for a "Welcome to Claude" banner that the Claude Code version I was running no longer printed. You only find that kind of failure by running the lane for real.
Quality Gates Between Agent Output and Action
The pattern gets you agents. It doesn't get you control. In production I put layered checks between what an agent returns and what the system does with it: deterministic checks first (free, instant, reproducible), a cross-check by a different model only when those pass.
Every dispatch runs the same lifecycle: PREPARE (one scoped instruction), GOVERN (the worker's structured report, validated) and RECEIPT (an append-only NDJSON receipt per dispatch). How those gates work in detail, including why a second LLM is not a guarantee, is in Async Quality Gates.
What Breaks and How to Fix It
- tmux session death. Checkpoint state to a local database after every significant output, or use ephemeral windows.
- Subprocess timeouts. Set generous timeouts for heavy tasks and use
Popenwhen you need visibility into long runs. - CLI format changes. Keep all CLI interaction in one adapter (variant D) and pin a known-good Claude Code version.
- Rate limits. Use a dispatch queue with a concurrency cap. I run four sessions at most.
- Permission prompts. Use a per-task
--allowedToolsallowlist instead of skipping permissions. - JSON parsing failures. Strip markdown fences and validate against a schema before using the result.
The Formal Audit
To be sure I wasn't accidentally in violation, I audited the entire VNX codebase on four questions:
| Question | Result |
|---|---|
| Does any code call Anthropic's OAuth endpoints or use stored OAuth tokens? | NO |
| Does any code call api.anthropic.com using subscription credentials? | NO |
Does it only launch claude CLI processes that authenticate themselves? | YES |
| Are there HTTP clients targeting Anthropic endpoints in executable code? | NO |
Every Anthropic domain reference turned out to be inert: documentation links, comments, template strings. The only OAuth and bearer tokens target Google Vertex AI and Perplexity. There are zero Anthropic SDK imports. The full audit is in the repository.
Is VNX an OpenClaw Replacement?
No, and I won't pretend it is. Different paradigm, different problem.
| Aspect | OpenClaw | VNX Orchestration |
|---|---|---|
| Philosophy | Personal assistant, any OS | Multi-agent governance with human gates |
| Trust model | Agent autonomy | Glass box: every action through dispatch and approval |
| Auth method | OAuth gateway (banned) | CLI subprocess (unaffected) |
| Audit trail | Not a primary concern | NDJSON receipt ledger with gate evidence |
| Skill ecosystem | 5,700+ on ClawHub (February 2026) | Focused native skills |
| Security record | Hundreds of NVD entries, supply chain attacks | No gateway, smaller attack surface |
| Scale (April 2026) | 340,000+ GitHub stars | A small open source project, one maintainer |
What VNX doesn't have: messaging integration for end users, a skill marketplace, multi-tenant support, or one-click installation. It is a single-operator system for governed multi-agent work, built on glass box governance principles. For how I moved my own OpenClaw-style workflows onto it, see how I replaced OpenClaw with Claude Code channels and a worker architecture.
If you need a polished, well-documented multi-agent framework today, use CrewAI or LangGraph with your own API keys. If you care most about knowing what your agents did, why, and whether a human approved it, that is the gap VNX fills.
What I'd Build Starting Today
- Pick your auth model first, not your framework. API keys for multi-user work. CLI subprocess for your own orchestration. Platform-native if you don't need custom governance.
- Start with the simplest framework that fits. Aider for single-agent coding, CrewAI for multi-agent, LangGraph for complex workflows. Anthropic's own advice: "The most successful implementations weren't using complex frameworks or specialized libraries."
- Add governance incrementally. One deterministic check between agent output and action. Then receipt logging. Then approvals.
- Never build on auth you don't control. That is the whole lesson of the OAuth ban.
- Assume your framework will die. Keep your gates, your audit trail and your business logic portable.
Compliance: What's Actually Allowed
Important:Claude Pro and Max subscriptions are for yourown use. Not for building commercial tools, not for reselling access, not for multi-tenant platforms.
I use VNX for my own work under my own subscription. It doesn't share credentials, proxy access for others, or run as a service. The CLI subprocess pattern enforces that by design: each user has to be logged in on their own machine.
If you need multi-user access to Claude, use the API with your own keys and your own billing. The same goes for any open harness that talks to the API itself: Anthropic does not allow subscription tokens there.
Frequently Asked Questions
Vincent van Deth
AI Strategy & Architecture
I build production systems with AI — and I've spent the last six months figuring out what it actually takes to run them safely at scale.
My focus is AI Strategy & Architecture: designing multi-agent workflows, building governance infrastructure, and helping organisations move from AI experiments to auditable, production-grade systems. I'm the creator of VNX, an open-source governance layer for multi-agent AI that enforces human approval gates, append-only audit trails, and evidence-based task closure.
Based in the Netherlands. I write about what I build — including the failures.