OpenClaw Patches Remote OAuth and Starts Untangling Its Doctor Command

Not every OpenClaw update gets a breathless headline. Some weeks, the most important work is the kind that prevents a support thread at 2 AM: an OAuth flow that stopped working after a dependency upgrade, and a diagnostic command that had gotten too big to maintain. Neither PR will trend on Hacker News. Both will save operators real headaches.

If you run OpenClaw on a remote VPS and use OpenAI Codex as a provider, there's a good chance your OAuth flow broke sometime in the last two weeks and you blamed your server configuration. You shouldn't have. The problem was upstream.

Version 0.60.0 of the @mariozechner/pi-ai dependency — which handles OAuth credential exchange — changed how it processes manual code input and callback URLs. OpenClaw's remote Codex wrapper wasn't passing the onManualCodeInput handler when operating in remote mode. The result: OAuth flows on headless VPS instances stalled silently. No error message. No fallback. Just a process waiting for a callback that would never arrive.

The fix is surgical — route the manual input handler through to the onPrompt callback when isRemote is true, leave the local flow unchanged. Users on remote instances can now paste either the authorization code or the full redirect URL manually. The fix touches exactly one file and has end-to-end test coverage.

This is the kind of dependency breakage that haunts self-hosted software. A transitive dependency bumps a minor version, changes the contract on a callback, and suddenly a feature that worked yesterday doesn't work today. The only defense is fast detection and fast patching — and to OpenClaw's credit, the turnaround here was quick.

OpenClaw's doctor command is the project's built-in diagnostic tool — a single command that checks your configuration, validates provider credentials, and warns about common misconfigurations. It's genuinely useful. It was also becoming a maintenance nightmare.

The core file, doctor-config-flow.ts, had accumulated provider-specific logic for every channel OpenClaw supports. Adding Telegram onboarding guidance? Edit the monolith. Adding group allowlist warnings? Edit the monolith. Every new provider feature meant touching the same file, with the same merge conflicts, and the same risk of breaking unrelated providers.

Maintainer vincentkoc's refactor extracts Telegram-specific warnings into a dedicated provider module at src/commands/doctor/providers/telegram.ts. The existing config flow becomes an orchestrator that delegates to provider-specific modules rather than containing all the logic itself. The refactor is explicitly scoped: only Telegram, no other providers, no changes to warning text or runtime behavior.

This is the right approach — extract one provider cleanly, validate the pattern, then repeat for Discord, Matrix, and Feishu. The Greptile security analysis rated it 5/5 confidence that the extraction is behavior-identical. Three new test branches cover fresh-install guidance, empty allowlist warnings, and fallback suppression.

The Pattern Here

These two PRs don't share a feature theme, but they share a maturity theme. The OAuth fix addresses the brittleness of dependency-driven auth flows in self-hosted environments. The doctor refactor addresses the organizational debt that accumulates when a project adds channels faster than it modularizes its tooling.

Both are investments in operational reliability over feature velocity — the kind of work that separates projects developers like to try from projects enterprises are willing to depend on. OpenClaw is doing more of this work lately, and that's worth noting even if it doesn't make for exciting changelogs.

For the full technical details, see PR #51631 and PR #51704 on GitHub.

Learn More

• OpenClaw GitHub Repository
• OpenClaw Documentation
• Deploy OpenClaw on Your Server