dsh web authentication required: reopen the printed URL

The message is not asking for a password. It is asking you to use the URL printed at startup. The token lives in the link, and opening the bare root address is refused.

The message, decoded

Split the notice into its parts.

The token is not a password. It is an access credential generated at startup and placed in the URL parameters; without it the service refuses the connection (source).

"Reopen" is not "refresh." Refreshing an old tab may reuse the old token; copy again from the terminal and open a new tab.

It usually appears in three situations: opening the root address directly, restarting the service so the token changed, or a link that was truncated or escaped.

Why the printed URL is required

The token in the URL is a credential, not decoration.

1. The service generates a token at startup and embeds it in the access address.
2. Requests must carry that token before the service allows them.
3. A bare root address has no token and is treated as unauthenticated.
4. A restart can change the token, invalidating old links.
5. Reopening the printed URL is therefore the direct fix.

The token is a temporary key. It proves the request comes from an authorized client; without it the service cannot separate legitimate access from scanning.

The printed URL is the only reliable source. A hand-typed, assembled or copied address may miss parameters or carry encoding errors.

Three ways to copy the URL

Pick one per environment, and avoid truncation.

1. Click in the terminal: terminals with hyperlink support let you click directly; watch for wrapped lines.
2. Copy the whole string: from http to the last parameter, not just the domain.
3. Open by command: in supported environments, pass the full URL to the system open command.

Paste into a scratch buffer first. Confirm there is no line break, space or ellipsis, then paste into the browser.

Do not assemble parameters by hand. The token is long and one missing character fails; copying the whole output is the stable path.

Four ways a token dies

These four account for most failures.

1. Service restart: a new token is generated and old links stop working.
2. Timeout: some builds use an expiry, after which you must obtain a new token.
3. Truncation: the tail of the parameters is lost during copying.
4. Encoding drift: chat apps or editors re-encode special characters.

Restart is the most common. Copy from the terminal on every launch instead of trusting an old bookmark.

Encoding is the most subtle. A link escaped by a chat client changes the token value; move it as plain text.

Recovering and verifying

Four steps restore access.

1. Return to the terminal running the service and find the newest printed URL.
2. Copy the whole string and open it in a new tab.
3. Confirm the page loads without the auth notice.
4. For long-term use, bookmark it, knowing you must recopy after expiry.
5. If it still fails, compare with another browser or a private window.

A new tab matters. The old tab may have cached the failure; a new tab starts clean.

A private window excludes cache and extension interference. If it still fails, move on to the server and network.

Security boundaries

A tokenized URL is a temporary key; handle it carefully.

1. Do not publish it: never paste it into group chats, issues or public docs.
2. Do not share screenshots: a screenshot can contain the full URL.
3. Issue per person: use an auth layer for multiple users instead of a shared token.
4. Rotate after exposure: regenerate when a leak or staff change occurs.
5. Authenticate public access: put login and origin limits at the reverse proxy.

A leaked token is leaked access. No account or password is needed; anyone with the link gets in, so limit the spread.

Never commit the token to code or config repositories. Use environment variables or a secrets manager so it does not travel with the source.

Troubleshooting

Four failure classes cover most authentication issues.

1. Auth notice persists: you opened the root or an old link; copy the full URL again.
2. Still failing after copying: the token is truncated or escaped; compare as plain text.
3. Another device cannot connect: the service listens locally or the LAN is restricted; fix reachability first.
4. Conflicts with several users: a shared token or a missing auth layer; add proxy authentication.

The order is link, network, auth layer. Confirm the link is complete, then the network, then whether a proxy is involved.

Logs show whether the request arrived. If it never arrived, it is a network problem; if it arrived and was rejected, it is a token problem. Do not mix the two.

Next steps

Copy the full URL first, then check network and auth layer. For general auth diagnosis, read Fixing web authentication required. For ports and auth, read dsh web auth and ports. For remote access, read Configuring remote access.

Sources: dsh CLI README, DeepSeek Harness documentation, deepseek-harness repository