Composer Predictions 1.2.4 — Tab autocomplete and inline continuation for DeepSeek Harness desktop and web

[Stijnus]

Tab completion and AI autocomplete for DeepSeek Harness desktop and web. Version 1.2.3 is available on npm.

• Next message: after a reply, ghost text suggests your next message.
• Draft continuation: pause with the caret at the end to complete your draft.
• Tab accepts a completed candidate as an editable draft; it never sends.
• Alt+Down / Alt+Up cycle up to three candidates. Escape dismisses.
• Settings → General → Composer predictions switches both modes off.

Install or update

In the desktop app or Web GUI: Plugins → Install → dsh-composer-predictions, then restart Harness.

For a CLI profile (replace web with your profile name):

dsh plugin --profile web add dsh-composer-predictions

Source and full instructions · Latest release and download · npm package

Latest release: 1.2.3

1.2.3 narrows npm keyword metadata. Runtime behavior is unchanged from 1.2.2; this is not a verified fix for npm search visibility.

Included security and completion fixes from 1.2.2

Both prediction routes now require authenticated Harness owner access, including Host/Origin checks, before reading sessions or spending model tokens. Updating from earlier versions is recommended. Also fixed simultaneous-view cancellation, draft-cache collisions, partial output, IME resumption and stale ghosts after refused insertion. Requires Harness >=0.2.1-rc.3 <0.3.0-0.

36 automated tests pass. Both modes, Tab without sending, candidate cycling, Escape and the setting were tested in DSH macOS Electron 0.2.1-rc.3 and the Web GUI. A clean profile installed the public npm package successfully. These are author tests, not an independent security review.

Model use and privacy

The plugin sends the recent conversation, tool activity and draft to your session's configured model, at its lowest advertised reasoning effort. Predictions consume provider tokens and may incur charges even though they are absent from the session log and token meter. Suggestions never run tools or submit messages. Results are cached for unchanged context/drafts.

Add to Discover

Plugins → Discover → Index sources → add:

https://raw.githubusercontent.com/Stijnus/dsh-composer-predictions/main/market-index.json

Select Stijnus · DSH plugins. This is an optional custom source, not a claim of inclusion in the default market. MIT license.

---

中文：DeepSeek Harness 桌面端 / Web 输入补全，v1.2.3

回复后建议下一条消息，打字停顿时续写草稿；Tab 采纳已完成的候选为可编辑草稿，不会自动发送。Alt+↓/↑ 切换最多三个候选，Esc 关闭。设置 → 通用 → 输入预测可开关。预测调用当前会话的模型并消耗 token；不会写入会话日志或 token 统计。

桌面端：插件 → 安装 → dsh-composer-predictions，安装后重启 Harness。代码、演示和安装说明见上方仓库链接。

[xiaoshenming]

Another same-kind plugin here — thanks for the owner-admission pointer, it closed a real hole on our side.

We ship dsh-next-hint (turn-end → ghost → Tab, stateless host POST). Your 1.2.2 security note made me check ours: /api/next-hint was loopback + origin only, so any local process could POST a sessionId and spend tokens. 0.1.5 now does exactly ctx.connection.admit(req) + peer.principal.kind === "owner" (loopback/origin kept as defense in depth). Question: does your admit path still pass through the Desktop shell proxy, which deletes origin and sets its own auth cookie? We haven't re-run the Desktop proxy after the change.

Two other differences I'm noting for later: Alt+↑/↓ candidate cycling and the IME candidate-window key deferral (we currently just stop painting during composition). If you have a note on how you detect "the IME candidate window owns the arrow keys", I'd take it.

We're on rc.2 at the moment; your rc.3 requirement is a good reminder to test the upgrade — our source scan of rc.3 still finds conversation.composer.dock, data-input-scroll, data-composer-composing and captureInsertion/insertText, so it looks compatible.

[Stijnus]

Short answer on admit: yes, it still works through the Desktop shell proxy — but only because we don't check Origin ourselves.

What the shell does (verified in dsh-desktop's forwardWebRequest): it deletes host, origin, cookie and sec-fetch-site from the forwarded request, sets cookie to the dsh-auth-* value it obtained during its own /connect handshake, and lets Node's fetch set Host to 127.0.0.1:<port>.

That lands in admit() as:

1. isTrustedApiRequest — Host present and loopback → pass; sec-fetch-site stripped, so not cross-site → pass; origin === undefined → the same-authority comparison is skipped and it returns true.
2. browserAuth.isAuthenticated(request, secure) sees the injected dsh-auth-* cookie → returns the shared browserPeer.
3. That peer is constructed with principal: { kind: "owner" }, so the owner check passes.

The trap: if you add your own Origin or Sec-Fetch-Site requirement on top of admit, the Desktop path breaks silently — the proxy strips both, so there is no origin to compare. "No origin" has to be treated as the shell/browser-panel case; the real fence is the loopback Host plus the cookie. We special-case the shell nowhere, and that is the only reason it survives.

On the IME: we do not detect that the candidate window owns the arrows, because I don't believe there is a portable signal. We skip any key where event.isComposing === true || event.keyCode === 229, and separately keep a ref set on compositionstart and cleared on compositionend (capture phase, document level) so no request is issued and no ghost is painted while composing. That is a conservative "hands off during composition", not a guarantee: some IMEs commit the composition before dispatching the arrow key, and then the event is an ordinary key and we will cycle. If you find something better, I'd genuinely like to know.

Alt+↑/↓ is just that: when the ghost holds more than one candidate, Alt+Arrow prevents default, stops propagation, and rotates the index. The draft is untouched until Tab, so cycling never costs a model call.

On rc.2 → rc.3, your scan matches what we rely on — conversation.input.overlay, captureInsertion/insertText, and measuring the editor's box. We don't use data-composer-composing; we listen to the composition events directly, so that attribute going away wouldn't affect us.

Good to hear dsh-next-hint closed the token-spend hole. Loopback-plus-origin really does look like a fence until you remember any local process can forge both.

[xiaoshenming]

Answering your IME question, because the host already publishes the signal you were looking for.

In 0.2.2-rc.1 the composer root carries data-composer-composing, maintained by the host itself:

const syncComposition = () => {
  rootElement?.toggleAttribute("data-composer-composing", composing || editor.isComposing())
}

It is set on compositionstart, re-synced on compositionend, and the stylesheet keys off it too
([data-composer-composing] p:last-child:after { content: none }). We read that attribute synchronously
at decision time — once when deciding whether to ask, once before painting, once before accepting —
instead of keeping our own ref set. Two reasons it beat our first attempt:

• no ordering problem: the attribute flips inside the composition event, before any of our own state publication;
• the composer store lags a beat — during the first frame of a composition, getSnapshot().draft still holds the
  pre-composition text. That lag is exactly why our ghost used to flash once and then vanish.

Still not a guarantee about the candidate window (nothing is), but "hands off while the host says it is composing"
is the most reliable line I found.

On Origin: your warning applies to us too, and we are only on the safe side by construction. We check
isAllowedOrigin(header, port), and a missing header returns true ("no browser origin to distrust"),
with a unit test asserting it (tests/host/routes.test.mjs). So the Desktop path, where the shell strips it,
survives, while a foreign origin is still rejected. Anything stricter would have broken the shell silently.

Re-checked the seams against the installed 0.2.2-rc.1 build (app.asar) as well:
conversation.composer.dock is { kind: "list", scope: "session" } rather than single, and
captureInsertion / insertText are unchanged. data-composer-composing is still published there,
if you ever want a cheaper signal than your own listeners.