Repository navigation
auth.json not loaded automatically in new sessions — provider Authorization header missing #36181
Description
Description
After configuring providers via /connect (which stores API keys in ~/.local/share/opencode/auth.json), opening a new session of opencode in a new terminal window fails to send the Authorization header when calling the provider API.
For example, with NVIDIA provider configured properly in both opencode.json (models) and auth.json (API key nvapi-...), using /model in a new session returns:
Unauthorized: Header of type `authorization` was missing
Running /connect again in the same session and re-entering the same key fixes it immediately — proving the key in auth.json is correct but was not loaded by opencode on startup.
Steps to reproduce
- Configure NVIDIA provider via
/connect, which stores the key inauth.json - Verify
auth.jsoncontains a valid entry:{"nvidia": {"type": "api", "key": "nvapi-..."}} - Verify
opencode.jsonhas the provider and models configured:"nvidia": { "models": { "deepseek-ai/deepseek-v4-pro": { "name": "DeepSeek V4 Pro" } } }
- Close terminal, open a new terminal
- Run
opencodeand use/modelto select the NVIDIA model - Actual result: Provider returns
Unauthorized: Header of type authorization was missing - Run
/connect, select NVIDIA, re-enter the same key - Use
/modelagain - Expected result: Works correctly
Workaround
Running /connect manually every session and re-entering the API key works, but defeats the purpose of persistent auth storage in auth.json.
Environment
- OpenCode version: [please specify]
- OS: Windows 11
- Terminal: Windows Terminal / PowerShell
Related issues
- Concurrent Auth.set/remove race and silently drop providers in auth.json #30396 — Concurrent Auth.set/remove race condition can silently drop providers in auth.json (may be a root cause)
Metadata
Metadata
Assignees
Labels
No labels
Activity
hui6900 commentedon Aug 5, 2026
[SUPERSEDED] — See this comment for the verified conclusion (direct SSH testing): the 401 in our environment is serve's own HTTP Basic Auth gate (client lacked
OPENCODE_SERVER_PASSWORD), andauth.jsonwas intact and its key valid. The "auth.json not loaded" framing below is retracted; theauth.jsonpath claims were also corrected in this comment.Adding a data point from our deployment: this issue also affects
opencode serve(headless server mode) after a process restart, not only new TUI sessions.Environment
opencode serverunning as a systemd user service, listening on port 40961.18.13_F050429(custom fork build)Symptoms
opencode serveprocess, every LLM request returns401 Unauthorized— the provider credentials inauth.jsonare not loaded by the new process.auth.jsonexists at both candidate paths and holds the expected provider entries (no corruption observed):/root/.local/share/opencode/auth.json/root/.config/opencode/auth.json/connectto re-authenticate, so the 401 state persists until the process is externally stopped/reconfigured.This looks like the same "auth.json not loaded on startup" root cause as described here, manifesting in serve mode instead of a new TUI session. The concurrent-write race referenced in #30396 also seems plausible as a root cause for a restart scenario. Happy to run a debug build or capture startup logs if that helps narrow it down.
hui6900 commentedon Aug 5, 2026
Correction to my previous comment (facts verified on the server, 2026-08-05):
Some details in my earlier comment were not accurate. Verified facts below:
/root/.local/share/opencode/auth.jsonexists (202 bytes, JSON is valid, contains two provider entries:deepseek,moonshotai-cn)./root/.config/opencode/auth.jsondoes not exist — my earlier "exists at both candidate paths" was wrong.ExecMainStartTimestamp = 2026-08-05 16:57:22 CSTfor the runningopencode.service(MainPID 369912). I could not verify a restart at 16:13 CST.GET http://127.0.0.1:4096/v1/models→401with empty body; also401when sendingAuthorization: Bearer <OPENCODE_SERVER_PASSWORD>andx-opencode-token. I cannot yet tell whether this 401 comes from serve's own password gate or from provider auth not being loaded — the auth header format for the serve API is not confirmed.1.18.13_F050429at/root/.opencode/bin/opencode(note:F050429looks like a custom build marker).I'll update this comment if I can pin down whether the 401 is caused by
auth.jsonnot being loaded (the root cause this issue is about) versus serve's own auth gate.hui6900 commentedon Aug 5, 2026
Final verification result (direct SSH test on the server, 2026-08-05, per my earlier "I'll update this comment"):
The 401 we hit is serve's own HTTP Basic Auth gate, not an auth.json loading problem.
Layer-by-layer curl results (all against the running
opencode serveon port 4096):GET /v1/models(no auth)401GET /v1/modelswithAuthorization: Basic base64(opencode:<OPENCODE_SERVER_PASSWORD>)200GET /with same Basic auth200GET /appwith same Basic auth200GET https://api.deepseek.com/modelswith the API key fromauth.json(Bearer)200auth.json(/root/.local/share/opencode/auth.json, the only path opencode reads — it usesGlobal.Path.data/auth.json) is intact (providers:deepseek,moonshotai-cn) and the stored key is valid against the provider API.opencode serveauthenticates correctly once the client sends the Basic credentials.So in our environment the observed 401 is the password gate rejecting an unauthenticated client — not a case of "auth.json not loaded on startup" as this issue describes. The earlier guesses in my first comment (and the plausible-cause framing) should be disregarded. If a client starts getting 401 after a serve restart, the more likely cause is that the client process does not have
OPENCODE_SERVER_PASSWORDset/matching the server's (the password inside a systemd unit is not automatically passed on to client processes), not thatauth.jsonwas dropped.oe3gwu commentedon Sep 19, 2026
same. but i added .local/share/opencode/auth.json and .config/opencode/opencode.json manually. They are 100% correct, but the model defined in opencode.json doesnt find its corresponding API Key. On V1 it works like a charm.