fix(e2e): fill the API key on the tab that actually holds it

[Ashin-LX-98]

Follow-up to #662. That one got connect to 5/6 — the first run to reach an actual LLM call — which is what exposed this.

The respond 0/6 root cause is in the spec, not in the adapters

The run's daemon.yaml (the env each agent process was really handed):

agent	injected
openclaw	LLM_API_KEY + LLM_BASE_URL=<gateway> + LLM_MODEL	✅
opencode	same	✅
codex	OPENAI_BASE_URL=https://api.openai.com/v1 + model, no key	❌
claude	ANTHROPIC_BASE_URL=https://api.anthropic.com + model, no key	❌
gemini	GOOGLE_GEMINI_BASE_URL=https://generativelanguage.googleapis.com, no key	❌

Those three are exactly the dual-auth agents, and their Configure dialog opens on the CLI sign-in tab (useState<"cli" | "key">("cli")). Radix unmounts the tab that is not selected, so the API-key form is not in the DOM: the spec enumerates [id^="agent-config-"], finds only the CLI tab's model fields, and fills no key.

save() then writes every field's stored default whatever the tab shows — which is where the official base URLs came from — and the key field is required: false on an agent that could equally be signed in, so the required-field guard did not object either. The dialog closed, connect passed, and the agent started with no credential.

Two rounds of reports read this as a gateway problem. It never was: those three requests never left the machine.

Fix: select the API-key tab before enumerating, and throw when no *_API_KEY input was filled. Saving an empty key silently is the part that cost the time, so it is now a loud failure with the field ids it did see.

Product side for this is two data-testid attributes on the tab triggers — the tab labels are translated, so there was no stable handle.

Also here, all from the same run's evidence

• Attachments are redacted. daemon.yaml carries the instance env verbatim, so the raw attachment put the gateway key and the workspace token into artifacts that outlive the run. Only the values this test knows are secret are masked, so the attachment stays diagnosable.
• HOMEDRIVE/HOMEPATH alongside USERPROFILE in the isolated HOME. openclaw's auth store turned up under the real profile during a run whose HOME was a temp dir, and a Windows tool resolving home from the older pair is the shape of that. Unproven — it is hardening in the right place, not a confirmed diagnosis.
• The daemon exit log now says how long the process lived, and words a clean stop apart from a failure. exited early was asserted, not measured: the handler outlives the spawn, so a deliberate stop minutes in printed the same alarming line as a spawn that died on the spot — which is why every daemon.log in the run carried one with nothing to date it. The failure wording keeps matching log-parser's error regex; a clean stop deliberately no longer does.

Testing

• npm run typecheck — clean
• npx vitest run — 48 files, 476 tests, all passing

Still open after this

• opencode reaches the gateway, declares the provider, opens a session, then neither errors nor replies until the 300s timeout. The same model answers a direct /v1/chat/completions in under a second, so this one needs its own investigation.
• openclaw fails inside its own CLI: requires legacy credential migration; run openclaw doctor --fix. Whether the HOMEDRIVE change removes it is a question for the next run.
• gemini's Approval mode overridden to "default" because the current folder is not trusted is untouched; its Invalid auth method selected should go with the key fix.
• The self-hosted orchestrator greps daemon.log. If anything there matches exited early, that string is gone now.

🤖 Generated with Claude Code

[vercel]

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

Project	Deployment	Actions	Updated
openagents-workspace	Ready	Preview	Sep 8, 2026 7:13am UTC