feat(onboarding): detect ACP login client-side via the bash endpoint (no SDK changes)

[simonrosenberg]

Summary

Auto-detect whether the chosen ACP provider (Claude Code / Codex / Gemini) is already signed in during onboarding, and show a "✓ you're already signed in" banner instead of unconditionally asking for an API key. Refs #964.

100% canvas — no SDK endpoint, no SDK release, no version pin. Detection is gated to local backends (where the provider CLIs and credential files live) and runs each provider's own status command through the existing agent-server bash endpoint, classifying the output.

How each provider is detected

Provider	Command (via BashClient.executeCommand)	Signal
Claude Code	claude auth status --json	loggedIn (exits non-zero when logged out, so we read the JSON, not the exit code)
Codex	codex login status	"Logged in …" / "Not logged in" — written to stderr, so both streams are checked
Gemini	test -f ~/.gemini/oauth_creds.json	no status command exists (browser OAuth) → credentials-file check

Anything that can't be classified — CLI not installed ("command not found"), unexpected output, or the bash call failing — is reported as unknown, so onboarding falls back to the API-key fields rather than a false banner.

Why this instead of a server-side probe

The earlier approach added an /acp/auth-status endpoint to the SDK (an ACP session/new handshake) + a typed client + a SHA pin. But the banner is local-only, so the protocol approach's headline benefit (topology-agnostic, works in cloud/docker) is unused — we only ever probe the user's own machine, where the CLIs and creds reliably exist. This collapses the whole feature to one canvas PR against the released client.

Honest trade-offs: Gemini is a credentials-file check (existence-based), Codex parses text output, and detection runs shell via the bash endpoint. All reliable locally; see discussion in #964.

Changes

• AcpService.getAuthStatus(server) (BashClient-based) → classified AcpAuthStatus.
• useAcpAuthStatus gated to local backends; no longer keys off API-key fields, so Gemini is detected too.
• Credentials step renders a login-status screen (banner, no inputs) for key-less providers; onboarding no longer skips slide 2.
• New i18n keys for the banner + Gemini login screen.

Tests / validation

• acp-service.api.test.ts: each provider's classifier incl. missing-CLI → unknown (the "no available ACP process" path); hook/step/modal tests cover gating, the Gemini login-only screen, and no-skip routing. typecheck + eslint + 40 tests green.
• Live, end-to-end through the Vite proxy → bash endpoint: Claude/Codex/Gemini → authenticated on a logged-in machine; a CLI stripped from PATH (exit 127) → unknown.

Supersedes

The protocol-probe approach — software-agent-sdk#3452, typescript-client#196, and the #971 wiring — can be closed in favor of this.

🤖 Generated with Claude Code

---

🐳 Docker images for this PR

• GHCR package: https://github.com/OpenHands/agent-canvas/pkgs/container/agent-canvas

Component	Value
Image	ghcr.io/openhands/agent-canvas
Architectures	amd64, arm64
Agent Server	ghcr.io/openhands/agent-server:1.24.0-python
Automation	openhands-automation==1.0.0a5
Commit	be1eeb008cd48c0976e6bd1cc678cb9aa4c07465

Pull (multi-arch manifest)

# Multi-arch manifest — Docker automatically pulls the correct architecture
docker pull ghcr.io/openhands/agent-canvas:sha-be1eeb0

Run

docker run -it --rm \
  -p 8000:8000 \
  ghcr.io/openhands/agent-canvas:sha-be1eeb0

All tags pushed for this build

ghcr.io/openhands/agent-canvas:sha-be1eeb0-amd64
ghcr.io/openhands/agent-canvas:feat-acp-auth-detect-canvas-amd64
ghcr.io/openhands/agent-canvas:pr-1002-amd64
ghcr.io/openhands/agent-canvas:sha-be1eeb0-arm64
ghcr.io/openhands/agent-canvas:feat-acp-auth-detect-canvas-arm64
ghcr.io/openhands/agent-canvas:pr-1002-arm64
ghcr.io/openhands/agent-canvas:sha-be1eeb0
ghcr.io/openhands/agent-canvas:feat-acp-auth-detect-canvas
ghcr.io/openhands/agent-canvas:pr-1002

About Multi-Architecture Support

• Each tag (e.g., sha-be1eeb0) is a multi-arch manifest supporting both amd64 and arm64
• Docker automatically pulls the correct architecture for your platform
• Individual architecture tags (e.g., sha-be1eeb0-amd64) are also available if needed

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
agent-canvas	Ready	Preview, Comment	Jun 1, 2026 10:04pm

[all-hands-bot]

✅ Review complete.

This review was performed through OpenHands Cloud Automation. You can log in and view the conversation here.

[github-actions]

✅ Mock-LLM Docker E2E Test Results

12/12 passed

Commit: 1b4dca57 · Workflow run · Test artifacts

Status	Test	Duration
✅	mock-llm-auth-modes.spec.ts › auth mode: non-public key rotation › recovers when localStorage has a stale session API key	3.8s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › shows the auth screen when no key is configured	1.1s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › rejects an incorrect key with an inline error	1.4s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › allows access after pasting the correct key	1.8s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › re-prompts when the server rotates its key (stale localStorage)	1.4s
✅	mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 1: setup LLM profile and register automation trajectory	513ms
✅	mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 2: create automation and dispatch run via the UI	28.7s
✅	mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 3: verify automation and run on the automations page	4.1s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 1: create an LLM profile pointing at the mock LLM server	4.2s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 2: activate the mock-llm profile and verify settings API	4.4s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 3: run a conversation with the mock LLM	4.3s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 4: resume conversation from sidebar after navigating away	3.7s

_{Posted by the Mock-LLM E2E workflow · results are deterministic (scripted LLM responses)}

[all-hands-bot]

Clean, well-scoped implementation. The detection logic is correctly fail-safe — any error, missing CLI, or unrecognised output falls back to unknown and shows the API-key fields rather than a misleading banner. Removing the slide-skip logic simplifies the modal significantly and the layered test coverage is excellent.

Three things worth addressing before merge, plus one note:

1. Test file placement — src/api/acp-service/acp-service.api.test.ts lives inside src/ while every other test file in this PR and the project lives under __tests__/. Should be __tests__/api/acp-service/acp-service.api.test.ts (see inline).
2. retry: false is dead code — probeAcpAuth catches all exceptions internally and always resolves, so React Query will never see a rejection to retry. Harmless today, but it could mislead a future author who removes the inner try/catch expecting this option to protect them (see inline).
3. classifyGemini substring match — The command controls the output precisely so no false positive is realistically possible, but comparing the trimmed value exactly would be more defensive (see inline).
4. i18n note — all 14 non-English locales duplicate the English strings. Normal for a new feature, but worth a follow-up issue so translated users aren't silently shown English.

This review was generated by an AI agent (OpenHands) on behalf of the user through OpenHands Automation. View conversation

[github-actions]

❌ Mock-LLM Docker E2E Test Results

11/12 passed · 1 failed

Commit: 06b9518a · Workflow run · Test artifacts

Status	Test	Duration
✅	mock-llm-auth-modes.spec.ts › auth mode: non-public key rotation › recovers when localStorage has a stale session API key	3.8s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › shows the auth screen when no key is configured	1.2s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › rejects an incorrect key with an inline error	1.3s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › allows access after pasting the correct key	1.4s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › re-prompts when the server rotates its key (stale localStorage)	1.5s
✅	mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 1: setup LLM profile and register automation trajectory	231ms
✅	mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 2: create automation and dispatch run via the UI	29.8s
✅	mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 3: verify automation and run on the automations page	4.1s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 1: create an LLM profile pointing at the mock LLM server	4.2s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 2: activate the mock-llm profile and verify settings API	4.3s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 3: run a conversation with the mock LLM	4.3s
❌	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 4: resume conversation from sidebar after navigating away	214ms

🔍 Failure details (1)

❌ mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 4: resume conversation from sidebar after navigating away

Error: page.goto: net::ERR_CONNECTION_REFUSED at http://localhost:18300/
Call log:
  - navigating to "http://localhost:18300/", waiting until "domcontentloaded"

_{Posted by the Mock-LLM E2E workflow · results are deterministic (scripted LLM responses)}

[simonrosenberg]

Addressed all three review threads in 7a4544d1 (test moved under __tests__/, exact-match classifyGemini, documented retry: false). On the i18n note (#4): the non-English placeholders match the repo's existing convention for new keys — agree it's worth a separate translation follow-up rather than this PR. Ready for another look.

[all-hands-bot]

✅ Review complete.

This review was performed through OpenHands Cloud Automation. You can log in and view the conversation here.

[all-hands-bot]

All three issues from the previous review have been addressed in 7a4544d — the test file is in the right place, retry: false has a clarifying comment, and classifyGemini now uses exact-string comparison. The code is clean, the fail-safe unknown fallback is applied consistently end-to-end, and removing the skip-slide logic is a genuine simplification.

One minor comment below on a stale code comment; everything else is ready to merge.

This review was generated by an AI agent (OpenHands) on behalf of the user through OpenHands Automation. View conversation

[github-actions]

✅ Mock-LLM Docker E2E Test Results

12/12 passed

Commit: 7a4544d1 · Workflow run · Test artifacts

Status	Test	Duration
✅	mock-llm-auth-modes.spec.ts › auth mode: non-public key rotation › recovers when localStorage has a stale session API key	3.8s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › shows the auth screen when no key is configured	1.2s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › rejects an incorrect key with an inline error	1.4s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › allows access after pasting the correct key	1.9s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › re-prompts when the server rotates its key (stale localStorage)	1.5s
✅	mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 1: setup LLM profile and register automation trajectory	472ms
✅	mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 2: create automation and dispatch run via the UI	28.9s
✅	mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 3: verify automation and run on the automations page	4.3s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 1: create an LLM profile pointing at the mock LLM server	5.2s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 2: activate the mock-llm profile and verify settings API	4.4s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 3: run a conversation with the mock LLM	4.3s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 4: resume conversation from sidebar after navigating away	3.9s

_{Posted by the Mock-LLM E2E workflow · results are deterministic (scripted LLM responses)}

[all-hands-bot]

✅ Review complete.

This review was performed through OpenHands Cloud Automation. You can log in and view the conversation here.

[all-hands-bot]

Clean implementation that achieves the stated goal — detecting ACP provider login client-side via bash commands, with a robust fail-safe unknown fallback throughout. All issues from the previous two review rounds have been addressed. The removal of the Gemini slide-skip logic is a genuine simplification, and the three-layer test pyramid (service → hook → component) gives solid confidence. Two small suggestions below.

This review was generated by an AI agent (OpenHands) on behalf of the user through OpenHands Automation. View conversation

[github-actions]

❌ Mock-LLM Docker E2E Test Results

11/12 passed · 1 failed

Commit: 0e82280c · Workflow run · Test artifacts

Status	Test	Duration
✅	mock-llm-auth-modes.spec.ts › auth mode: non-public key rotation › recovers when localStorage has a stale session API key	3.8s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › shows the auth screen when no key is configured	1.2s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › rejects an incorrect key with an inline error	1.3s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › allows access after pasting the correct key	1.5s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › re-prompts when the server rotates its key (stale localStorage)	1.5s
✅	mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 1: setup LLM profile and register automation trajectory	210ms
✅	mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 2: create automation and dispatch run via the UI	29.8s
✅	mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 3: verify automation and run on the automations page	4.4s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 1: create an LLM profile pointing at the mock LLM server	4.3s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 2: activate the mock-llm profile and verify settings API	4.5s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 3: run a conversation with the mock LLM	4.4s
❌	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 4: resume conversation from sidebar after navigating away	199ms

🔍 Failure details (1)

❌ mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 4: resume conversation from sidebar after navigating away

Error: page.goto: net::ERR_CONNECTION_REFUSED at http://localhost:18300/
Call log:
  - navigating to "http://localhost:18300/", waiting until "domcontentloaded"

_{Posted by the Mock-LLM E2E workflow · results are deterministic (scripted LLM responses)}

[all-hands-bot]

✅ Review complete.

This review was performed through OpenHands Cloud Automation. You can log in and view the conversation here.

[all-hands-bot]

All feedback from the three previous review rounds has been addressed — the test file is in the right place, classifyGemini reads only stdout with exact-string matching, retry: false has its explanatory comment, and the stale GET /api/acp/auth-status mention is gone. The implementation is clean and the fail-safe unknown fallback is applied consistently end-to-end.

One minor gap noted below on the translation strings. Everything else is ready to merge.

This review was generated by an AI agent (OpenHands) on behalf of the user through OpenHands Automation. View conversation

[github-actions]

✅ Mock-LLM Docker E2E Test Results

12/12 passed

Commit: be1eeb00 · Workflow run · Test artifacts

Status	Test	Duration
✅	mock-llm-auth-modes.spec.ts › auth mode: non-public key rotation › recovers when localStorage has a stale session API key	3.7s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › shows the auth screen when no key is configured	1.2s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › rejects an incorrect key with an inline error	1.4s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › allows access after pasting the correct key	1.8s
✅	mock-llm-auth-modes.spec.ts › auth mode: public gate › re-prompts when the server rotates its key (stale localStorage)	1.5s
✅	mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 1: setup LLM profile and register automation trajectory	503ms
✅	mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 2: create automation and dispatch run via the UI	29.7s
✅	mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 3: verify automation and run on the automations page	4.2s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 1: create an LLM profile pointing at the mock LLM server	4.2s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 2: activate the mock-llm profile and verify settings API	4.3s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 3: run a conversation with the mock LLM	4.3s
✅	mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 4: resume conversation from sidebar after navigating away	3.7s

_{Posted by the Mock-LLM E2E workflow · results are deterministic (scripted LLM responses)}

[github-actions]

📸 Snapshot Test Report

✅ All snapshots match the main branch baselines.

Category	Count
🔴 Changed	0
🆕 New	0
✅ Unchanged	73
Total	73

✅ Unchanged snapshots (73)

archived-conversation

• conversation-panel-with-archived-badges
• conversation-view-archived
• conversation-view-sandbox-error

automations

• automations-delete-modal
• automations-list-active-inactive
• automations-no-automations
• automations-search-no-results

backends-extended

• backend-add-blank-disabled
• backend-add-cloud-advanced-open
• backend-add-cloud-no-key-disabled
• backend-add-cloud-with-key-enabled
• backend-add-form-partially-filled
• backend-add-invalid-url-disabled
• backend-add-local-ready
• backend-add-name-only-disabled
• backend-add-two-column-layout
• backend-add-whitespace-host-disabled
• backend-after-switch
• backend-cancel-nothing-saved
• backend-dropdown-two-backends
• backend-edit-prefilled
• backend-manage-after-removal
• backend-manage-two-listed
• backend-remove-cancelled
• backend-remove-confirmation
• backend-switch-overlay

backends

• backend-add-modal
• backend-manage-modal
• backend-selector-open

changes-tab

• changes-deleted-file
• changes-diff-viewer
• changes-empty

collapsible-thinking

• reasoning-content-collapsed
• reasoning-content-expanded
• think-action-collapsed
• think-action-expanded

mcp-page

• mcp-custom-server-1-editor-open
• mcp-custom-server-2-url-filled
• mcp-custom-server-3-all-filled
• mcp-custom-server-4-installed
• mcp-custom-server-editor
• mcp-empty-installed
• mcp-search-filtered
• mcp-slack-install-1-marketplace
• mcp-slack-install-2-modal
• mcp-slack-install-3-filled
• mcp-slack-install-4-installed

onboarding

• onboarding-step-0-choose-agent
• onboarding-step-1-check-backend
• onboarding-step-2-setup-llm
• onboarding-step-3-say-hello

projects-workspace-browser

• projects-workspace-browser

settings-page

• add-backend-modal
• analytics-consent-modal
• home-screen
• settings-app-page
• settings-page

settings-secrets

• secrets-add-form-filled
• secrets-add-form
• secrets-after-save
• secrets-delete-confirm
• secrets-list

settings-verification

• condenser-settings
• verification-settings-off
• verification-settings-on

sidebar

• sidebar-collapsed
• sidebar-conversation-panel
• sidebar-filter-menu

skills-page

• skills-empty
• skills-loaded
• skills-no-match
• skills-search-filtered
• skills-type-filter

---

Generated by the Snapshot Tests workflow. This comment was created by an AI agent (OpenHands) on behalf of the repo maintainers.