DeepSeekDSH
Fix an error中文GitHub
Menu
Independent community guideNot affiliated with DeepSeek.Download versions and guide references
HomeRelease notes

DeepSeek Harness v0.1.2-alpha.2: Connection Recovery Becomes Visible

Source-backed notes on DSH v0.1.2-alpha.2: visible disconnect states, automatic retry, manual reconnect, 2-second heartbeat checks and how to verify recovery behavior.

Maintained by DeepSeekDSH (independent site)
On this page
Historical release note

Released on August 30, 2026, v0.1.2-alpha.2 introduced visible connection states, automatic retry and manual reconnect.

Release fact

DeepSeek published v0.1.2-alpha.2 on August 30, 2026 at 13:52:14 UTC. The official release notes list a new Web UI connection-error state with automatic retry and immediate reconnect support.

v0.1.2-alpha.2 GitHub Release ↗

Why this matters for long-running agents

A short command can simply fail and be retried. A remote gateway, persistent Agent or long Web session can sit in an ambiguous state where users cannot tell whether the model is still working, the network is backing off, or the transport is dead. Alpha.2 turns that ambiguity into an observable connection lifecycle that users can watch and interrupt.

The Web UI exposes three recovery phases

Disconnected

A warning indicator appears near Settings instead of leaving the user with a silent or ambiguous failure.

Connecting

Automatic retry remains visible while the connection layer is attempting recovery. Hovering or focusing exposes the reconnect action.

Recovered

After a disconnected/connecting state returns to connected, the UI shows a success confirmation for 2,000 ms before returning to the normal state.

What the source actually changed

The user-facing indicator and the transport recovery logic landed in separate commits. Reading both is important: one explains what the user sees, the other explains who owns retry timing and physical socket replacement.

feat(web): add connection recovery indicatorAdds disconnected, connecting and recovered UI states; the warning state is keyboard-focusable/clickable; the recovered confirmation timeout is set to 2,000 ms.refactor(connection): centralize websocket recoveryMoves retry/backoff ownership into the connection controller, adds reconnect() to cancel the current socket or retry delay and start a fresh attempt, preserves logical remote streams across physical carrier generations, and changes the default WebSocket heartbeat interval from 30,000 ms to 2,000 ms. The server also terminates sockets that fail heartbeat liveness checks.
Important distinction

The default heartbeat interval is two seconds. Heartbeats detect dead connections, while the connection controller schedules reconnect attempts through progressive backoff.

How to verify alpha.2 recovery behavior

  1. 01

    Start a remote or long-running Web session

    Use a session where losing the transport would otherwise be easy to confuse with a slow model response.

  2. 02

    Interrupt the network temporarily

    Confirm that a visible disconnected/connecting state appears instead of relying on a blank or apparently frozen interface.

  3. 03

    Restore the network

    Watch automatic retry recover the connection and confirm the short recovered-success state is shown.

  4. 04

    Test manual reconnect during backoff

    While the connection is waiting or attempting recovery, use the reconnect control and confirm it interrupts the current attempt/delay and starts a fresh connection attempt.

The recovery path kept evolving after alpha.2

v0.1.2-alpha.3 fixed backend stalls being mistaken for network disconnections. v0.1.2-alpha.4 added agent and long-session changes, and v0.1.2-alpha.5 fixed upgrade startup failures and missing session-list titles.

v0.1.2-alpha.3Open alpha.3 releasev0.1.2-alpha.4Open alpha.4 releasev0.1.2-alpha.5Open v0.1.2-alpha.5 releasev0.2.1-alpha.5Read the October v0.2.1-alpha.5 plugin and terminal fixes
Sources

GitHub Release, Connection indicator commit, WebSocket recovery commit