[Feature Proposal] Configurable idle Enter behavior: Enter = Send or Newline (Cmd/Ctrl+Enter to send)

[foo-hao]

Summary

This proposal adds a user-facing preference to the Web composer: when the agent is idle, pressing Enter can either send the message (current default, unchanged) or insert a newline — with Cmd/Ctrl+Enter always sending. This matches the familiar chat-style keybinding (Slack/WeChat/Telegram desktop). When the agent is running, the existing busyEnter Queue/Steer mapping is fully preserved.

A complete, ready-to-review implementation is available on my fork (single commit, based on current master, ahead 1 / behind 0):

• Branch: https://github.com/foo-hao/deepseek-harness/tree/feat/idle-enter-mode-open-source
• Commit: foo-hao@0edcb6d
• Patch (compare): master...foo-hao:feat/idle-enter-mode-open-source

Behavior

State	Enter	Cmd/Ctrl+Enter	Shift+Enter
idle, enterMode: send (default)	send	send	newline
idle, enterMode: newline	newline	send	newline
running (busyEnter: queue/steer)	unchanged Queue/Steer mapping	unchanged	newline

Key design points:

• The preference is stored in Host settings and persisted via settings.yaml (survives refresh, port changes, and other hosts).
• In idle newline mode, the textarea placeholder preserves its current action prompt and appends the Enter/Cmd/Ctrl shortcut meanings; Send mode, busy input, and unavailable composers keep their existing prompts.
• The idle/busy split is intentional: while an agent is running, Enter keeps its Queue/Steer semantics exactly as today; the new mode only affects the idle composer.
• Explicit regression coverage: when enterMode: newline and busyEnter: steer are both enabled, plain Enter still steers and Cmd/Ctrl+Enter still queues. This historical conflict is locked in by tests.
• A new "Enter behavior while idle" selector appears in General Settings; the UI is fully localized (en/zh) with an ARIA snapshot.

Why

The composer previously hard-coded idle Enter to send. Users who prefer "Enter = newline, Cmd/Ctrl+Enter = send" had to maintain local bundle patches that are lost on every upgrade. The default behavior is unchanged, so this is purely additive.

Verification

• pnpm exec vitest run — 7 related ui-conversation test files, 118 cases passed
• Final Queue/Steer combination regression — 72 cases passed
• Real Web e2e (settings-chrome, DSH_SNAPSHOT=replay) — 8 cases passed
• pnpm run build, pnpm run lint, pnpm run doc-sync (28/28), pre-push typecheck — all green
• Diff: 27 files, all belonging to this feature; no unrelated changes

Question for the team

Per CONTRIBUTING.md, external pull requests are not accepted at the moment, so I am posting this as a proposal first. The patch is ready to merge as-is when/if that policy changes, and I am happy to adjust it to the team's preferences — including re-shaping it as an ecosystem plugin if composer behavior should be made pluggable.

---

中文摘要

为 Web 输入框增加"空闲时 Enter 行为"偏好：默认保持 Enter 发送（现状不变）；可切换为 Enter 换行、Cmd/Ctrl+Enter 发送（聊天软件习惯按键）。agent 运行中完全保留现有 Queue/Steer 映射，并显式回归了 Newline 与 Steer 同时开启时的冲突（Enter 仍 Steer、Cmd/Ctrl+Enter 仍 Queue）。设置通过 settings.yaml 持久化（跨刷新、端口和 Host）。Newline 模式会在可用的空闲输入框 placeholder 中保留当前操作提示并追加快捷键说明。完整实现已推送到 fork（单提交、基于最新 master，ahead 1/behind 0），验证全过：单测 118 用例、真实 Web e2e 8/8、build/lint/doc-sync 28/28 全绿。按 CONTRIBUTING 说明，外部 PR 当前暂不可提交，先发此贴让团队知晓；可随时按团队要求调整，或改走插件生态路线。

[zoahdev]

提案质量很高（默认不变=纯增量、idle/busy 分离、Newline 与 Steer 并存的回归锁定），补两个对决策有用的点：

1. 关于"改走插件生态路线"——这条路今天不通，建议留在仓库内

composer 的按键行为在 client 端包里：packages/client/ui-conversation/src/submission-settings.ts（BUSY_ENTER_FIELD / BusyEnterBehavior）+ input bar 组件，编译进 web bundle。而 dsh.bundle.patch 只能 patch host 侧设置，无法往编译后的 React 代码里注入按键逻辑——所以插件路线需要一个"客户端扩展接缝"，而这类接缝目前不存在（#3186 讨论的就是同类缺口：第三方插件拿不到请求/UI 层接缝）。结论：这个功能做成仓库内提案是当下唯一可行路径；等将来有 web-extension 接缝（比如 #3186 的中间件层落地后演进出的 UI 插件点）再考虑插件化也不迟。

2. 一个可发现性建议

enterMode: newline 开启后，新用户大概率不知道 Cmd/Ctrl+Enter 能发送（这是该模式最大的行为变化）。建议在输入框 placeholder 或底部提示里按模式动态显示提示（如 "Enter 换行 · Cmd/Ctrl+Enter 发送"），比在设置页藏一个下拉框更容易被发现——也能顺带缓解"设置里找不到为什么 Enter 不发送了"的困惑。

回归测试（busyEnter:steer + enterMode:newline 时 Enter 仍 Steer、Cmd/Ctrl+Enter 仍 Queue）正是这个功能最容易踩的坑，你已经锁死了，赞。diff 27 文件全属本功能 + build/lint/doc-sync/typecheck 全绿，合并风险很低。

[foo-hao]

Thanks — both points are useful.

I agree that the current plugin surface cannot modify the client-side composer, so keeping this as a repository-level proposal is the practical path unless the team prefers introducing a client extension seam.

The discoverability point also makes sense. A mode-aware composer hint such as “Enter inserts a newline · Cmd/Ctrl+Enter sends” would make the behavior self-explanatory. I will treat that as a candidate follow-up, with matching i18n and accessibility coverage.

I am keeping the current one-commit review branch stable while the maintainers evaluate the proposal. If the team prefers the inline hint, I can add it promptly without changing the existing idle/busy semantics.

[foo-hao]

Update: I implemented the mode-aware placeholder hint in the same one-commit branch.

When an available idle composer uses enterMode: newline, the textarea keeps its current action prompt and appends the Enter/Cmd/Ctrl shortcut meanings. Live preference changes update it immediately, and the Plan and owner-provided prompts are preserved. Send mode, busy input, and unavailable composers keep their existing prompts, so the Queue/Steer behavior and default UI remain unchanged.

The InputBar suite now has 73 passing cases, including the new live-mode and prompt-preservation coverage. The full GUI suite passed 3,795 tests, the focused Web settings scenario passed 8/8, and doc-sync passed 28/28. Updated commit: foo-hao@0edcb6d

[foo-hao]

Thanks @zoahdev for the detailed feedback. Following up on this proposal against the current public master, d347e70 (v0.1.3-alpha.1).

The implementation linked in the original post already includes the mode-dependent placeholder hint: in idle newline mode it preserves the action prompt and adds the Enter / Cmd-or-Ctrl+Enter shortcut explanation. Thank you for highlighting discoverability.

The patch and test results in the original post describe the August implementation baseline. The next reviewable revision will target the current composer architecture and carry fresh validation results for that revision.

I would like to keep this proposal focused on the idle Enter preference: Send as the default, optional Newline, Cmd/Ctrl+Enter to send while idle, Shift+Enter for newline, and the existing busy Queue/Steer behavior preserved. Validation will include IME composition, locked/unavailable input, preference persistence, shortcut hints, and the idle/busy keybinding combinations.

Following the current contribution guide, I am continuing here in Discussions. For maintainers reviewing this idea: would you prefer this as a built-in conversation setting, or a client extension point through which an ecosystem plugin can implement the behavior? If there is an existing design or preferred integration surface, a pointer would help align the refreshed patch.

中文补充：继续跟进这个单一功能。原实现已包含换行模式下的快捷键提示；原帖验证结果对应当时的实现基线。后续可评审版本会适配当前主线并重新验证。希望确认团队更倾向于内置会话设置，还是提供客户端扩展点供插件实现，以便按项目方向整理改动。