Android WebAPK cold launch withholds SameSite=Strict session cookie and returns 401 (0.1.2-alpha.2)

[tomcatzh]

Summary

On Android, an installed Chrome WebAPK for dsh web can fail on a cold top-level launch with:

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

The same DSH origin remains authenticated and functional in the ordinary Chrome tab. The installed app's initial root request is a cross-site top-level navigation, so Chrome withholds DSH's SameSite=Strict browser-session cookie on that request.

This report is not asking to remove browser authentication, accept a non-authentication cookie as authentication, or change the signed authentication cookie to SameSite=None.

Version and environment

• DSH: dsh-v0.1.2-alpha.2
• Exact commit: 0a53fb55bea101816fa226bb964ae2bed71c343b
• Relevant implementation: packages/client/connection/src/browser-auth.ts
• Client: Android Chrome, installed WebAPK / installed web app
• DSH origin: loopback HTTP (http://127.0.0.1:<port>)

No launch token, cookie value, credential, session content, workspace data, or other sensitive value was recorded for this report.

User-facing reproduction

1. Start dsh web on a loopback port.
2. In ordinary Android Chrome, open the launch URL printed by DSH and complete the normal token-to-cookie exchange.
3. Confirm that the clean root URL works in Chrome.
4. Install the page as an Android web app/WebAPK.
5. Fully close the installed app, then launch it from its home-screen icon.
6. Observe the authentication-required 401 page in the installed app.
7. Return to the ordinary Chrome tab at the same clean root URL; it remains authenticated and functional.

For controlled validation, I also navigated the standalone WebAPK to the one-time launch URL using local test tooling, without logging or persisting the token. This confirmed that the app could hold a valid signed authentication cookie. After force-stopping and cold-launching the WebAPK, the first root navigation still reproduced the failure before the compatibility patch described below.

The installed app cannot normally edit its fixed launch URL to add a fresh process token. Retaining a launch token in the installed URL would also violate the intended token-to-cookie exchange model.

Sanitized Fetch Metadata evidence

The failing cold launch has this request shape:

GET / HTTP/1.1
Host: 127.0.0.1:<port>
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-Dest: document
Cookie: [the SameSite=Strict DSH authentication cookie is absent]

This is a top-level document navigation, not a cross-site API call or iframe request. Once navigation is established on the DSH origin, a subsequent same-origin navigation can carry the existing Strict authentication cookie normally.

Expected behavior

A previously authorized installed WebAPK should be able to resume the same authenticated loopback session after a cold launch while preserving the current security properties:

• the signed authentication cookie remains authority-bound, HttpOnly, and SameSite=Strict;
• API, RPC, and WebSocket requests still require that signed cookie;
• the process launch token remains limited to the existing root exchange;
• no token is exposed to application JavaScript, persisted in the installed URL, or placed in frontend state;
• Host, Origin, and Fetch Metadata checks remain intact for privileged routes;
• missing or malformed bootstrap state fails closed.

Actual behavior

The first WebAPK request is classified as cross-site. Chrome therefore does not send the Strict authentication cookie, authorizeIndex() sees an unauthenticated root request, and DSH returns its normal 401 text response. The installed app cannot reach a same-origin navigation from which Chrome would send the existing Strict cookie.

Relation to #5063

This is related to #5063, but it is a different browser topology.

#5063 concerns a UI that remains inside a cross-site iframe/WebView, where HTTP and WebSocket traffic continues to be third-party. This report concerns only an Android-installed WebAPK's initial top-level cold launch. After one constrained same-origin navigation, the official Strict cookie works normally for the page, API, and WebSocket.

A one-hop top-level bootstrap can therefore address this case without defining or weakening a persistent cross-site embedding contract.

Reference implementation

I have a source-level alpha.2 reference patch available for review. It uses the following fail-closed mechanism:

1. Keep the existing signed authentication cookie unchanged as HttpOnly; SameSite=Strict.

2. On a successful token exchange, also set an authority-derived, fixed-value, HttpOnly; SameSite=Lax launch marker.

3. Never accept that marker in isAuthenticated() or as authentication for index, API, RPC, or WebSocket routes.

4. Only when all of the following are true:

   • the signed authentication cookie is absent;
   • the exact authority-derived marker is present;
   • the request is GET /;
   • Sec-Fetch-Site: cross-site;
   • Sec-Fetch-Mode: navigate;
   • Sec-Fetch-Dest: document;

   return a no-store 401 HTML bootstrap containing only a CSP-hash-authorized location.replace('/').

5. The replacement performs a same-origin navigation, allowing the existing Strict authentication cookie to be sent.

6. Every other unauthenticated request retains the current plain 401 behavior.

The bootstrap also sends frame-ancestors 'none', default-src 'none', base-uri 'none', form-action 'none', Referrer-Policy: no-referrer, and X-Content-Type-Options: nosniff.

The Lax marker is deliberately not an authentication credential. Even if supplied alone, privileged requests continue to receive 401. Its only effect is selecting one static root self-navigation. The marker name includes the normalized authority, although cookies themselves are not port-scoped; maintainers may prefer a signed or shorter-lived marker even with its non-authentication role.

Validation performed

The reference patch includes tests for:

• both cookies' attributes, with the authentication cookie remaining Strict;
• marker-only isAuthenticated() returning false;
• marker-only real CLI API access returning 401;
• the exact cross-site top-level document request receiving the constrained CSP bootstrap;
• absent, malformed, same-origin, non-document, non-root, and HEAD requests retaining the plain 401 response;
• existing authority binding and signed-cookie persistence across process restart;
• multiple Set-Cookie handling in connection, gateway, and stream fixtures.

On a real Android installed WebAPK, the patched build passed two consecutive force-stop/cold-launch cycles with a clean URL and no authentication error; the ordinary Chrome DSH tab remained healthy.

Known gaps

• The automated tests model Fetch Metadata and server behavior but do not run an Android WebAPK. The device validation above was manual/test-harness validation; an upstream-owned browser test would still be valuable.
• Additional negative tests should explicitly cover missing or wrong Sec-Fetch-Mode, missing or wrong Sec-Fetch-Dest, and a marker minted for a different hostname or port.
• Existing alpha.2 users would need one fresh token exchange after adopting this mechanism because already-issued authentication cookies have no launch marker.
• The approach relies on Chromium rendering the no-challenge 401 HTML and treating the scripted replacement as a same-origin navigation; this should be checked against the browser versions upstream intends to support.

Would the maintainers consider this narrowly scoped top-level launch bootstrap, or prefer another mechanism that preserves the Strict authentication cookie while supporting installed Android WebAPKs?

[dhanjit]

Corroborating this on desktop and iOS, and on a much broader trigger than an installed PWA: any cross-site top-level arrival, in an ordinary browser tab.

Same mechanism you describe — authorizeIndex requires the dsh-auth-* cookie, which is SameSite=Strict, so the browser withholds it whenever the navigation is initiated by another site.

Minimal repro, one browser, two navigations seconds apart, one variable changed, already-authenticated session in both:

1. Type the dsh URL in the address bar → the app loads.
2. From any other origin (https://example.com), navigate to the same URL (a link click or location.href) → dsh web authentication required; reopen the URL printed by dsh web.
3. Reload that error page → the app loads again.

So the everyday triggers are not exotic: tapping a link to dsh from a chat or mail client, and — for anyone running dsh behind an identity proxy — the redirect back from the login host after re-authenticating, which for us lands on this error on a fixed weekly cadence.

Environment: dsh 0.1.5-rc.1, HTTPS via a reverse proxy on the same host, Chrome on desktop and Safari on iOS. No token, cookie value, or other credential was recorded for this report.

Noting for others who arrive here: the workaround is a reload or a typed URL/bookmark, and an application-layer gateway in front does not help, because its own cookie is Lax and is sent — the gateway admits the request and dsh then rejects it.

[crjase]

[Bug + Verified Fix] Android installed web app loses authentication on cold launch — confirmed on DSH 0.2.1-rc.5

Summary

I'm reporting an independently reproduced authentication issue affecting DeepSeek Harness when installed as an Android web app.

The regular browser can access the authenticated Web UI successfully, but launching the installed application from the Android home screen results in an authentication failure.

I traced the problem to the browser-session cookie's hardcoded SameSite=Strict attribute and verified that changing it to SameSite=Lax resolves the issue in my environment.

This confirms that the behaviour previously described in Discussion #5362 also affects the newer 0.2.1-rc.5 release.

Environment

Component | Configuration -- | -- DeepSeek Harness | @deepseek-ai/dsh@0.2.1-rc.5 Host OS | Arch Linux Android device | Google Pixel 10 Browser | Brave for Android Installation | Brave's installed web application Server | Local HTTP listener on port 3080 Remote access | HTTPS reverse proxy through private Tailscale network

Steps to reproduce

1. Start DeepSeek Harness Web.

2. Open its generated authentication URL containing ?token=... in Brave on Android.

3. Allow the token exchange to complete.

4. Confirm that the clean base URL loads successfully without the token.

5. Install the website as an Android application through Brave.

6. Close the browser and launch the installed app from the Android home screen.

Actual result: The installed application fails authentication, even though the same base URL remains accessible in the normal Brave browser.

Expected result: An already-authenticated installed application should reopen successfully without requiring another token exchange.

Root cause

The browser-session authentication implementation in:

packages/client/connection/src/browser-auth.ts

issues its signed authentication cookie with the hardcoded attribute:

SameSite=Strict

An installed Android web application's initial navigation can be classified as cross-site, even when the destination is the same previously authenticated origin.

Consequently, the browser may omit the Strict authentication cookie from the initial request.

The server receives a request without its authentication cookie and returns HTTP 401.

This creates an inconsistent experience:

• Opening the site directly in Brave succeeds.

• Launching the installed application fails.

• The authentication cookie itself remains valid.

• The installed application cannot automatically recover through an authenticated same-origin navigation.

The failure is caused by cookie transmission rules, not by invalid API credentials, expired authentication, or network connectivity.

Confirmed workaround

I tested the following change in the installed runtime:

Package: @deepseek-ai/dsh-client-connection

File: lib/index.js

Original:

- SameSite=Strict
+ SameSite=Lax

After applying the change:

1. I restarted DeepSeek Harness.

2. I completed one fresh authentication-token exchange.

3. I reopened the Android-installed application.

4. The application authenticated successfully.

This establishes a direct correlation between the cookie's SameSite policy and the observed failure.

The workaround does not remove authentication, modify the signing mechanism, or disable the existing Host/Origin checks.

However, I recognize that changing the SameSite policy changes the browser's cookie-sending behaviour and should receive a security review before being adopted upstream.

Proposed upstream solution

I recommend addressing Android installed-app startup within the browser authentication implementation.

Preferred approach: preserve SameSite=Strict and implement a safe same-origin bootstrap.

When a previously authenticated installed application initiates a cross-site top-level navigation without its Strict cookie, the server should provide a tightly scoped recovery navigation that allows the browser to submit the existing cookie on a subsequent same-origin request.

The recovery mechanism must not grant access based solely on a bootstrap marker or request metadata.

An alternative would be to expose a documented configuration option allowing an explicitly selected SameSite=Lax policy while retaining Strict as the default.

For example:

cookieSameSite: strict # strict | lax

This would provide compatibility for Android installed applications without silently changing authentication behaviour for existing deployments.

Security requirements

Any accepted implementation should preserve:

• Signed, authority-bound browser-session cookies.

• Existing token-based initial authentication.

• Host and Origin validation.

• Existing authentication for privileged HTTP, RPC and WebSocket endpoints.

• Protection against unauthenticated access.

• Normal cookie expiration and session revocation.

A compatibility marker, if introduced, must never independently authorize privileged requests.

Suggested regression tests

• Existing valid browser sessions continue working.

• Authenticated Android-style cold launches recover successfully.

• Initial cross-site navigation is handled without exposing credentials.

• Unauthenticated requests remain unauthorized.

• API and WebSocket routes reject requests without a valid signed session.

• Incorrect authorities and expired cookies remain rejected.

• Ordinary desktop browser navigation remains unchanged.

• Session authentication continues working after a server restart.

• The compatibility mechanism does not introduce redirect loops.

Related discussions

• #5362 — Android installed application authentication failure

• #9096 — SameSite=Strict causes authentication problems when navigating from external applications

Contribution

I have reproduced the issue on a current 0.2.x release and validated a minimal runtime workaround on a physical Android device.

I'm interested in contributing a source-level fix with regression tests.

Given that external pull requests are currently restricted, I'd be happy to publish the implementation on a fork for maintainer review or cherry-picking.

The goal is to make DeepSeek Harness reliable as an installed Android web application without compromising its existing authentication guarantees.

# [Bug + Verified Fix] Android installed web app loses authentication on cold launch — confirmed on DSH 0.2.1-rc.5

Summary

I'm reporting an independently reproduced authentication issue affecting DeepSeek Harness when installed as an Android web app.

The regular browser can access the authenticated Web UI successfully, but launching the installed application from the Android home screen results in an authentication failure.

I traced the problem to the browser-session cookie's hardcoded SameSite=Strict attribute and verified that changing it to SameSite=Lax resolves the issue in my environment.

This confirms that the behaviour previously described in [Discussion #5362](#5362) also affects the newer 0.2.1-rc.5 release.

Environment

Component	Configuration
DeepSeek Harness	@deepseek-ai/dsh@0.2.1-rc.5
Host OS	Arch Linux
Android device	Google Pixel 10
Browser	Brave for Android
Installation	Brave's installed web application
Server	Local HTTP listener on port 3080
Remote access	HTTPS reverse proxy through private Tailscale network

Steps to reproduce

1. Start DeepSeek Harness Web.
2. Open its generated authentication URL containing ?token=... in Brave on Android.
3. Allow the token exchange to complete.
4. Confirm that the clean base URL loads successfully without the token.
5. Install the website as an Android application through Brave.
6. Close the browser and launch the installed app from the Android home screen.

Actual result: The installed application fails authentication, even though the same base URL remains accessible in the normal Brave browser.

Expected result: An already-authenticated installed application should reopen successfully without requiring another token exchange.

Root cause

The browser-session authentication implementation in:

packages/client/connection/src/browser-auth.ts

issues its signed authentication cookie with the hardcoded attribute:

SameSite=Strict

An installed Android web application's initial navigation can be classified as cross-site, even when the destination is the same previously authenticated origin.

Consequently, the browser may omit the Strict authentication cookie from the initial request.

The server receives a request without its authentication cookie and returns HTTP 401.

This creates an inconsistent experience:

• Opening the site directly in Brave succeeds.
• Launching the installed application fails.
• The authentication cookie itself remains valid.
• The installed application cannot automatically recover through an authenticated same-origin navigation.

The failure is caused by cookie transmission rules, not by invalid API credentials, expired authentication, or network connectivity.

Confirmed workaround

I tested the following change in the installed runtime:

Package: @deepseek-ai/dsh-client-connection

File: lib/index.js

Original:

- SameSite=Strict
+ SameSite=Lax

After applying the change:

1. I restarted DeepSeek Harness.
2. I completed one fresh authentication-token exchange.
3. I reopened the Android-installed application.
4. The application authenticated successfully.

This establishes a direct correlation between the cookie's SameSite policy and the observed failure.

The workaround does not remove authentication, modify the signing mechanism, or disable the existing Host/Origin checks.

However, I recognize that changing the SameSite policy changes the browser's cookie-sending behaviour and should receive a security review before being adopted upstream.

Proposed upstream solution

I recommend addressing Android installed-app startup within the browser authentication implementation.

Preferred approach: preserve SameSite=Strict and implement a safe same-origin bootstrap.

When a previously authenticated installed application initiates a cross-site top-level navigation without its Strict cookie, the server should provide a tightly scoped recovery navigation that allows the browser to submit the existing cookie on a subsequent same-origin request.

The recovery mechanism must not grant access based solely on a bootstrap marker or request metadata.

An alternative would be to expose a documented configuration option allowing an explicitly selected SameSite=Lax policy while retaining Strict as the default.

For example:

cookieSameSite: strict # strict | lax

This would provide compatibility for Android installed applications without silently changing authentication behaviour for existing deployments.

Security requirements

Any accepted implementation should preserve:

• Signed, authority-bound browser-session cookies.
• Existing token-based initial authentication.
• Host and Origin validation.
• Existing authentication for privileged HTTP, RPC and WebSocket endpoints.
• Protection against unauthenticated access.
• Normal cookie expiration and session revocation.

A compatibility marker, if introduced, must never independently authorize privileged requests.

Suggested regression tests

• Existing valid browser sessions continue working.
• Authenticated Android-style cold launches recover successfully.
• Initial cross-site navigation is handled without exposing credentials.
• Unauthenticated requests remain unauthorized.
• API and WebSocket routes reject requests without a valid signed session.
• Incorrect authorities and expired cookies remain rejected.
• Ordinary desktop browser navigation remains unchanged.
• Session authentication continues working after a server restart.
• The compatibility mechanism does not introduce redirect loops.

Related discussions

• [#5362 — Android installed application authentication failure](Android WebAPK cold launch withholds SameSite=Strict session cookie and returns 401 (0.1.2-alpha.2) #5362)
• [#9096 — SameSite=Strict causes authentication problems when navigating from external applications](Browser session cookie: SameSite=Strict causes a redirect loop on iOS when the page is opened from another app #9096)

Contribution

I have reproduced the issue on a current 0.2.x release and validated a minimal runtime workaround on a physical Android device.

I'm interested in contributing a source-level fix with regression tests.

Given that external pull requests are currently restricted, I'd be happy to publish the implementation on a fork for maintainer review or cherry-picking.

The goal is to make DeepSeek Harness reliable as an installed Android web application without compromising its existing authentication guarantees.