feat(onboarding): auto-detect ACP subscription/login via /api/acp/auth-status#971
Open
simonrosenberg wants to merge 2 commits into
Open
feat(onboarding): auto-detect ACP subscription/login via /api/acp/auth-status#971simonrosenberg wants to merge 2 commits into
simonrosenberg wants to merge 2 commits into
Conversation
…h-status Onboarding now probes whether the chosen ACP provider's CLI is already authenticated (Claude Pro/Max, ChatGPT, Google subscription — or a pre-set API key) and shows a "✓ you're already logged in" banner instead of unconditionally asking for an API key. Refs #964. Detection rides the agent-server's purpose-built endpoint added in software-agent-sdk#3452, which drives the ACP initialize + session/new handshake server-side (no prompt → no model tokens) and returns authenticated / unauthenticated / unknown. - `AcpService.getAuthStatus(server)` wraps the new `AcpClient` from `@openhands/typescript-client`, keeping all agent-server access typed (the no-direct-agent-server-calls guard stays satisfied). - `useAcpAuthStatus` now calls `GET /api/acp/auth-status` instead of the canvas-only "Phase 0" throwaway-conversation probe (closed PR #968). A failed/unreachable probe falls back to "unknown" so we never falsely claim "not logged in". The hook's public shape is unchanged, so the onboarding banner UI carried over from #968 did not change. - Gated to local backends with credential fields; cached per provider per backend; never blocks the (skippable) step. The `@openhands/typescript-client` dependency is temporarily pinned to the `AcpClient` commit (OpenHands/typescript-client#196) by SHA so this can be validated end-to-end before that PR is released; swap to the released version once published. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
…roviders)
Gemini was the one provider the feature most benefits — it logs in via Google
OAuth, so a user with no API key is exactly who should see "✓ you're already
signed in" — yet it was never probed. The probe was gated on "does this provider
have API-key fields" (`getAcpProviderSecrets(...).length > 0`), and the
onboarding flow skipped the whole credentials slide for Gemini. The agent-server
can detect Gemini fine (the handshake returns authenticated / auth_required).
- `useAcpAuthStatus`: drop the `hasCredentials` gate — eligibility is now just
"local backend". The server returns `unknown` (422 → caught) for anything it
can't probe, so coupling to key-fields was both wrong (excluded Gemini) and
unnecessary. `AcpAuthStatus` now aliases the client's `ACPAuthStatusValue`
instead of a hand-redefined union.
- Onboarding modal: every non-OpenHands provider now shows slide 2, so the
`skipStep2` machinery (nav deltas + progress-bar remapping) is deleted — the
flow is a plain 4-step sequence again.
- Credentials step: for providers with no key fields it renders a login-status
screen — "Sign in to {provider}" + a browser-OAuth subtitle, the "you're
already signed in" banner when authenticated, and no inputs. Claude Code /
Codex are unchanged (key fields + banner).
- New i18n: ACP_LOGIN_TITLE, ACP_LOGIN_SUBTITLE, ACP_AUTH_DETECTED_NO_KEY.
Tests: hook now asserts Gemini IS probed; modal asserts slide 2 renders as a
key-less login screen (no skip, 4 segments); step asserts the login-only render.
Refs #964
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
📸 Snapshot Test Report✅ All snapshots match the main branch baselines.
✅ Unchanged snapshots (73)
Generated by the Snapshot Tests workflow. This comment was created by an AI agent (OpenHands) on behalf of the repo maintainers. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Phase 1 canvas side of #964. During ACP onboarding (Claude Code / Codex / Gemini), the credentials step now detects whether the chosen provider's CLI is already authenticated — by a subscription login (Claude Pro/Max, ChatGPT, Google) or a pre-set API key — and shows a "✓ you're already logged in" banner instead of unconditionally asking for an API key.
Detection rides the agent-server's purpose-built endpoint from software-agent-sdk#3452, which drives the ACP
initialize+session/newhandshake server-side. No prompt is sent, so it spends no model tokens, and because the probe runs inside the agent-server it reports the truth for wherever the agent actually runs.Changes
AcpService(src/api/acp-service/acp-service.api.ts) — wraps the newAcpClientfrom@openhands/typescript-client, constructed from the active backend's client options, so all agent-server access stays typed (theno-direct-agent-server-callsguard stays satisfied).useAcpAuthStatusnow callsGET /api/acp/auth-statusinstead of the canvas-only "Phase 0" throwaway-conversation probe (closed PR feat(onboarding): detect existing ACP subscription/login (Phase 0, canvas-only) #968, which was a false positive — conversation-create doesn't run the handshake). A failed/unreachable probe falls back to"unknown", so we never falsely claim "not logged in". The hook's public shape is unchanged.Temporary SHA pin
@openhands/typescript-clientis pinned by SHA to theAcpClientcommit (OpenHands/typescript-client#196) so this can be validated end-to-end before that PR is released. Swap to the released version once published.Validation
npm run typecheck,eslint,prettier --check: clean.vitest runforuse-acp-auth-status, the two onboarding step/modal tests, and theno-direct-agent-server-callsguard: green.Dependencies
Refs #964
🤖 Generated with Claude Code
🐳 Docker images for this PR
• GHCR package: https://github.com/OpenHands/agent-canvas/pkgs/container/agent-canvas
ghcr.io/openhands/agent-canvasghcr.io/openhands/agent-server:1.24.0-pythonopenhands-automation==1.0.0a5f76d648195cf1c51f27af830427c2a406e4b4e66Pull (multi-arch manifest)
# Multi-arch manifest — Docker automatically pulls the correct architecture docker pull ghcr.io/openhands/agent-canvas:sha-f76d648Run
All tags pushed for this build
About Multi-Architecture Support
sha-f76d648) is a multi-arch manifest supporting both amd64 and arm64sha-f76d648-amd64) are also available if needed