cc-viewer 1.9.9 → 1.9.11

package/README.md

@@ -202,7 +202,7 @@ cc-viewer works in a single container or on a cloud host where you reach the UI
 * **Plaintext secrets stay on the host.** The IM/DingTalk status endpoint tells a remote admin the process/connection state (so the UI can show "connected"), but plaintext app secrets are only ever returned to a loopback (`127.0.0.1`) client.
 * **Internal machine bridges stay loopback-locked.** The hook/notify channels the local `claude` process uses (turn-end, session-start, task-event, stream chunks) still require a loopback peer plus the per-boot internal token — remote admins cannot reach them.
 * **IM workers stay on `127.0.0.1`.** Each DingTalk/IM worker binds loopback inside the container; the main process probes it over `127.0.0.1`. In a single container this needs no extra setup.
-* **Security recommendations for a public/cloud deployment:** enable password login (or keep the random `?token=` URL secret), and put the instance behind a reverse proxy that terminates HTTPS. Persist the log/settings directory by mounting a volume at the path pointed to by `CCV_LOG_DIR` (default `~/.claude/cc-viewer`) so your preferences, auth password, and IM credentials survive container restarts.
+* **Security recommendations for a public/cloud deployment:** enable password login (or keep the random `?token=` URL secret), and put the instance behind a reverse proxy that terminates HTTPS. The proxy must preserve the original `Host` header (and should set `X-Forwarded-Proto`): WebSocket upgrades and management write endpoints validate the browser `Origin` against `Host`, so a proxy that rewrites either header will get those requests rejected. Persist the log/settings directory by mounting a volume at the path pointed to by `CCV_LOG_DIR` (default `~/.claude/cc-viewer`) so your preferences, auth password, and IM credentials survive container restarts.
 * **Reverse-proxy note:** access control is based on the socket peer address (`X-Forwarded-For` is deliberately not trusted, to prevent spoofing). This does not affect remote admins — they authenticate by token/password, not by IP. It only means "same-container" detection relies on a real loopback connection.
 
 * **Design doc:** how local config maps to a cloud database and the cloud-sync model (cloud-authoritative, local read-only fallback) is described in [Config Convergence & Cloud-Sync Advisory](./docs/config-cloud-sync.md) ([中文](./docs/config-cloud-sync.zh.md)). This is a proposal, not yet implemented.

package/cli.js

@@ -868,9 +868,10 @@ async function runSdkMode(extraClaudeArgs = [], cwd, noOpen = false) {
       try { serverMod.broadcastTurnEnd(sessionId, ts, null, cwd); }
       catch (err) { console.warn('[sdk] broadcastTurnEnd threw:', err?.message); }
     },
-    // query 级失败(spawn/protocol/iterator)推到 Web UI toast —— 此前只有 console.error,
-    // 死掉的 query 在 UI 上看与挂起无异。
-    onQueryError: (message) => serverMod.broadcastWsMessage({ type: 'sdk-error', message }),
+    // Query-level failure (spawn/protocol/iterator) → Web UI. The frame feeds a
+    // persistent dialogue row plus a toast; meta (cwd/sessionId/instanceKey, filled by
+    // the sdk-manager session closure) routes it to the owning workspace's viewers.
+    onQueryError: (message, meta) => serverMod.broadcastWsMessage({ type: 'sdk-error', message, ...(meta || {}) }),
   });
 
   // Per-cwd multi-session (2026-10-12): hand the boot launch config (proxy env, model,