dsh-deepseek-webchat

LIMITATIONS

Known limitations

These are real, and worth knowing before you rely on the plugin. **HttpOnly cookies cannot be restored.** The DSH Host runs as a separate Node child process, not inside Electron, so the plugin cannot reach Electron's cookie store. It can only read `document.cookie` from inside the guest, and HttpOnly cookies are invisible there by design. In practice DeepSeek keeps its credential in `localStorage.userToken` and sends it as a bearer token, so replaying site storage is what restores your login — but if DeepSeek ever moves its credential to an HttpOnly cookie, this plugin will start asking you to sign in again after each restart. **The guest partition is per-run.** The shell hands out a process-lifetime session partition and the plugin cannot ask for a different one. Login survival is therefore the snapshot-and-replay above, not a persistent browser profile. **One DeepSeek login, shared.** Every DSH Session shares a single DeepSeek account and browser session; the per-Session split is the conversation, not the login. Separate DSH Sessions do **not** get separate DeepSeek accounts. **Binding happens on the first message.** DeepSeek creates a conversation only when you send something, so a DSH Session stays unbound until you send at least one message in the page. Until then the toolbar dot is hollow. **A very long session lists only its newer rows.** The picker pages backwards from the newest rows, and a reply larger than ~2 MB of text is not worth moving through the HTTP route into a React list, so the host leaves the oldest rows out and the list says how many. This only affects sessions in the thousands of rows (and, with 高级 on, sessions with tens of megabytes of tool output). Individual rows are also capped at 4000 characters — a picker row is one line tall, and the outliers are 40–50 KB tool results. **DeepSeek can change its page.** The composer fill targets `textarea.ds-textarea__textarea`, and the conversation id is read from DeepSeek's `/a/<agent>/s/<id>` route. If DeepSeek redesigns either, the fill or the binding stops working until this plugin is updated. The rest of the plugin — embedding, login, per-Session tabs — is unaffected. **Desktop only.** The embedded page needs the desktop browser guest channel. In a plain `dsh web` profile the panel says so instead of falling back to an iframe (which DeepSeek would refuse anyway, via `frame-ancestors 'none'`). **One DeepSeek tab per DSH Session.** The tab kind is single-instance, so you cannot open two DeepSeek panels side by side for the same Session.