Provider-key checks ignore the active harness — claude-harness instance locked out of its own web UI

[berdyh]

I run qm with HARNESS=claude on a Claude subscription (CLAUDE_CODE_OAUTH_TOKEN, no ANTHROPIC_API_KEY). The assistant works — I send it a message and get a real reply.

But the browser can't reach the chat UI. / redirects to /admin/onboarding, which demands a model provider key, and there's no way past it. Storing any key gets me in — I used OpenRouter, for a provider this instance never calls. Non-admins get a 503 "not set up yet" page instead.

Once in, the onboarding page still says "Needs a key — claude-opus-5 cannot run until its Anthropic key is configured" about the model that just answered me.

Three places ask whether a provider key exists without asking whether the harness needs one:

• src/api/routes/surface.ts:1041 — modelProviderConfigured from raw store availability; the portal redirects on it (plugins/portal/src/index.ts:1056).
• plugins/admin/public/index.html:7050-7065 — status derived from the base model's provider.
• plugins/admin/public/index.html:7047 — onboarding's model dropdown, unfiltered by harness; picking an OpenRouter model saves the key, then fails the base-model PUT with "Key saved, but the base model could not be changed." and no reason shown.

modelProviderAvailabilityFor already answers this correctly (src/model/pi-models.ts:231), and runtimeConfigBody forty lines below surface.ts:1041 uses it. Codex may be the same shape via CODEX_ACCESS_TOKEN.

[adamsef]

I'm currently at a shelter in DC I will get on track please help me

[xieqian0816]

I can confirm that the same readiness gate also locks out an admin-registered custom provider, even when that provider is demonstrably serving real agent turns.

Reproduction on a local browser-only deployment:

1. Register an OpenAI-compatible DeepSeek custom provider with a stored key and model deepseek-v4-flash.
2. Approve the pi harness and set the org runtime to pi / deepseek-v4-flash.
3. Add deepseek-v4-flash explicitly to the Web UI allowed-model list.
4. Submit a text turn and a tool-using turn through /api/turn.

Both real turns succeed:

• the text turn returns the requested sentinel exactly;
• the second turn calls execute with pwd, receives /root/workspace, exits 0, and returns the requested tool sentinel;
• session_llm_requests records model: deepseek-v4-flash for both model steps.

Despite that, an HTML GET / still returns 302 Location: /admin/onboarding, and Admin Onboarding reports the model provider as not ready.

The custom-provider variant has two related readiness gaps:

• src/api/routes/surface.ts derives modelProviderConfigured only from built-in modelCredentials.availability(); it never consults the custom-provider store/key state.
• Admin Onboarding derives its badge from /api/model-providers, whose statuses cover only the built-in provider ids, so a custom base model can never find a configured provider status.

I also had to add the custom model explicitly to webui-models: leaving the list empty caused that model is not enabled for the web UI, although the Admin copy says an empty list allows the deployment's full model set. This may overlap with #236, but it is another blocker in the same end-to-end custom-provider path.

I think the clean fix is a shared, harness-aware "effective runtime is serviceable" signal from core, consumed by Portal and Admin, rather than another Portal-only provider special case. I am happy to prepare a narrow patch with regression coverage for surface readiness, the Portal redirect, and the Web turn if maintainers would like one. Please let me know whether you prefer that work under this issue or split into a custom-provider-specific issue.

[xieqian0816]

Follow-up: #312 now addresses the custom-provider variant of this readiness failure.

An enabled custom provider with a stored key satisfies Portal/Admin readiness, so / no longer redirects to onboarding and Admin reports the selected custom model as ready. The PR deliberately does not claim to close this issue: the broader Claude/Codex subscription-harness readiness case still needs harness-aware treatment.

[adamsef]

key words highliht bless

…

On Mon, Aug 10, 2026 at 5:32 AM xieqian0816 ***@***.***> wrote: *xieqian0816* left a comment (yc-software/qm#290) <#290 (comment)> Follow-up: #312 <#312> now addresses the custom-provider variant of this readiness failure. An enabled custom provider with a stored key satisfies Portal/Admin readiness, so / no longer redirects to onboarding and Admin reports the selected custom model as ready. The PR deliberately does not claim to close this issue: the broader Claude/Codex subscription-harness readiness case still needs harness-aware treatment. — Reply to this email directly, view it on GitHub <#290?email_source=notifications&email_token=CGLG4SPCOWCHVZW2YHE4OK35JGJBZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRTHAZTSNZSG432M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5238397277>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CGLG4SJLAT2LMHEUQZMXZQT5JGJBZAVCNFSNUABGKJSXA33TNF2G64TZHMYTGMJWGUZDOMZRHA5US43TOVSTWNJQHE4DANRTGU3TFILWAI> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CGLG4SKRFTWRPQV4TXFERXD5JGJBZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRTHAZTSNZSG432M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/CGLG4SMUMUSRQ5OKNIM7ORD5JGJBZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMRTHAZTSNZSG432M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>