First-run Web UI appears stuck until API key and workspace are configured

[MMZYNAY]

Summary

Fresh dsh web deployment can look stuck on first launch because the composer is disabled, but the UI does not clearly explain the two required setup steps in-place:

1. configure a DeepSeek API key, and
2. add/select a workspace.

The docs mention this, but the first-run screen itself only shows a disabled composer with placeholder text, and the API key modal blocks interaction until it is dismissed or configured.

Environment observed

• Package: @deepseek-ai/dsh 0.1.0-rc.6
• Command: npx @deepseek-ai/dsh web
• URL: http://127.0.0.1:3080/
• OS: Windows 11 Pro 64-bit, version 10.0.26200
• Node.js: v24.18.0
• npm: 11.16.0
• Browser check: Chrome via Playwright against local server
• Boot rev shown by page: dcccb8324e44

What I saw

1. GET / returns the Web UI successfully and all initial JS/CSS/plugin assets load with HTTP 200.
2. The page renders with an API key modal:
   • title: 添加一个 API Key 开始使用
   • body: 配置 DeepSeek 官方模型，即可开始使用。
   • 保存并继续 stays disabled until a key is entered.
3. If I click 稍后配置, the modal closes, but the composer is still disabled because no workspace is selected.
4. POST /api/workspace.list returns an empty list: items: [].
5. POST /api/credentials.describe reports DEEPSEEK_API_KEY.configured: false.
6. No JS page errors or failed HTTP requests were observed; the only console message was Chrome's generic DOM warning about a password input not being inside a form.

Why this is confusing

For a new user deploying the harness, the page can look like the deployment failed even though the server is healthy. The UI says 选择一个工作区开始, but it is not obvious that both model configuration and workspace selection are required before the input/send controls become usable.

Suggestion

Consider adding a first-run checklist or disabled-state explanation near the composer, e.g.:

• 1/2 Configure API key with a button to open Settings → Models
• 2/2 Add/select workspace with a button to open the workspace picker
• If either blocker is missing, show it directly beside the disabled composer/send button.

Also consider persisting 稍后配置 for the current browser/profile so the API key modal does not repeatedly appear after reload when the user intentionally skips it.

[MMZYNAY]

Update with the actual failing symptom from the user's browser:

The Settings → Models page can fail with:

加载提供方目录失败: transport failure for /api/llm.providers: HTTP 403

I reproduced the trust-gate behavior locally: /api/llm.providers returns 403 when the request Host and Origin authorities differ, e.g. request URL/Host is 127.0.0.1:3080 but Origin is http://localhost:3080.

POST http://127.0.0.1:3080/api/llm.providers
Origin: http://localhost:3080
=> HTTP 403 forbidden

With a matching origin, the transport passes the trust check:

POST http://127.0.0.1:3080/api/llm.providers
Origin: http://127.0.0.1:3080
=> HTTP 200

This explains why the same local deployment can work in one browser/session but show the 403 in another. The UI currently surfaces the low-level transport error, but not the likely cause or remediation. It may help to either normalize/canonicalize loopback aliases for same-origin checks (localhost vs 127.0.0.1) where safe, or show a targeted message such as “Open the UI using the same loopback host that loaded the page; avoid mixing localhost and 127.0.0.1; hard refresh/clear this site’s data if cached assets came from another host.”