dsh web authentication required: how to fix the prompt

The message dsh web authentication required; reopen the url printed by dsh web. does not mean the service is broken—it means "open the tokenized address the terminal printed" (source). This guide targets that exact string across three directions: what it means, the correct fix, and why the auth works this way.

dsh web authentication required; reopen the url printed by dsh web.

Overview: read the DeepSeek Harness prompt in one line

The operative phrase is reopen the url printed by dsh web—it wants the printed address, not the 127.0.0.1:3080 you typed. The DeepSeek Harness Web UI uses startup token authentication: the process generates a random token on each start, prints a root URL with ?token= exactly once, and only visiting that URL exchanges the token for a browser cookie (source). So this prompt almost always means: you are visiting an address that carries no auth info.

What the prompt means: why typing 127.0.0.1:3080 into DeepSeek Harness does not count

Because the listen address and the auth address are two different things: the former only says where the service is, the latter carries the token needed to exchange a session.

1. dsh web prints one tokenized root URL at startup, shaped like http://127.0.0.1:3080/?token=.... Expected: it prints once, and the token never hits disk.
2. Only visiting that URL exchanges the process token for a cookie, after which it redirects to a clean / and later requests authenticate via the cookie. Expected: the address bar returns to / without the token, and access is normal.
3. Any request without a valid cookie gets the same minimal 401, which in the browser shows as this prompt. Expected: you see the auth notice page, not the normal UI.

Two common misreads worth clearing up: static assets stay public, so "images load" does not mean auth passed; and 403 is not 401—403 means the origin is untrusted (Host / Origin check failed) while 401 means no valid browser session. For the fuller mechanism and port troubleshooting, see dsh web authentication required and port 3080.

The fix: three steps to restore DeepSeek Harness access

Ordered from least to most invasive: exchange the printed URL for a cookie first, then reset at the session level, and only then change environment.

1. Copy the full terminal URL — go back to the terminal running dsh web and copy the whole ?token= address into the browser. Expected: the page redirects to a clean / and auth passes.
2. Token expired or URL lost → restart for a new one — the token is not persisted, so restarting dsh web prints a fresh tokenized URL to exchange. Expected: you get the new URL and get in.
3. Changed port / browser → re-authenticate there — the cookie is bound to hostname and port, so a new port invalidates the old cookie; authenticate once with the new URL in the new browser. Expected: normal access in the new environment.

If even the terminal output is gone, follow step 2—restart for a new URL. If it still prompts after restarts, move on to the broader troubleshooting of credential files and session revocation, which is a separate branch.

The security side: why DeepSeek Harness auth exists and why the URL is a secret

Auth exists so that only someone local who has seen that one-time address can get in.

• Why auth is needed: dsh web binds only 127.0.0.1, yet any local process might try to reach it; the startup token narrows "can open the UI" to "can see the terminal output", a minimal line of defense.
• Never share the tokenized URL: the address is equivalent to a credential, and whoever has it can exchange it for a valid session. Do not paste it into chat windows, issues, or group chats, and crop it out of screenshots.
• Remote access done right: dsh web refuses to bind 0.0.0.0 and does not imply network deployment or TLS support. For remote use, open it locally over an SSH port-forward rather than opening up the listen address.

Once you are in, extending DeepSeek Harness happens in the same place as always: search and install plugins at DSH Plugin Hub.

Notes on the DeepSeek Harness authentication prompt

1. Check the terminal first: the top suspect for this prompt is always "did not use the tokenized URL", so copy the address from the terminal instead of restarting or reinstalling.
2. The token prints once: refreshing a page or opening a new tab is not "reopening the printed address"; if it is lost you must restart for a new one.
3. Do not force 127.0.0.1:3080: it is the listen address with no auth info, so opening it always prompts for auth.
4. Separate 401 from 403: 401 is a missing session, 403 is an untrusted origin, and they are fixed differently.
5. Treat the URL as a password: a tokenized URL is a process credential, and sharing it hands over the UI.

Sources: Agent Note: browser startup token authentication, dsh CLI README