[Desktop] The queued-message "Send now" (立即发送) button only reorders the queue — it never steers or starts a turn, and a refused steer fails silently

The report identifies renderer/assets/workspace-screen-*.js for sendQueuedMessageNow and the steer effect, plus main/index.js for steerAgentTurn and liveRunOwner. Read those paths first and trace the queued send and refusal behavior; the issue provides reproduction steps using a running turn and a queued follow-up. Done means Send now delivers or starts the queued message, and a refused steer gives the user feedback or a working fallback.

Title

[Desktop] The queued-message "Send now" (立即发送) button only reorders the queue — it never steers or starts a turn, and a refused steer fails silently

Summary

On Desktop 0.1.57 (Windows), a message sent while the agent is working appears as a queued bubble with a ↵ affordance on its left. Hovering it shows "Send now" (zh: “立即发送”; aria-label = "Send queued message now"). Users read that as "deliver this message now, into the running turn". It does not.

There are two separate defects:

1. The button never sends anything. Its handler sendQueuedMessageNow only moves the item to the front of the queue (and un-steers other queued items on the same thread). It never calls the steer channel (window.electronAPI.steerAgent) and never starts a turn. With a single queued message, the reorder is a no-op, so the click produces no visible change at all — the button looks broken. When the queue does reorder, the message still waits for the current turn to end, which is the opposite of what the label promises.

2. The real steering path is automatic and silent. A separate useEffect calls steerAgent for queued messages. When the main process refuses — liveRunOwner() finds no activeRun and no inFlightSessions reservation — it returns { accepted: false, error: "No run in progress." } and the renderer returns without a notice, a retry, or a fallback to a normal send/queue drain. The message stays in the queue with a spinner and nothing tells the user why.

This is not hypothetical: the maintainer's reply on #46 already documents the "send now only moves it to the front" behaviour, but the UI copy and the silent refusal still make it look like a broken control.

Expected Behavior

• "Send now" should actually send now. Concretely: if a run is live, steer the message into it; if no run is live, start a new turn (or hand it to the idle-drain path immediately). Reordering alone should not be presented as "send now".
• If the click cannot do anything, say so. A toast/inline notice such as "message not delivered — tap to resend" beats a silent no-op.
• A refused steer must not be silent. On { accepted: false } the renderer should notify, retry with backoff, and fall back to sending once the thread is idle.

Actual Behavior

1. Start a turn; while it is running, type a follow-up and press Enter → it appears as a queued bubble with a spinner.
2. Click the ↵ on the queued bubble (tooltip "立即发送" / "Send now").
3. Nothing happens. The bubble stays queued; it is only delivered when the current turn ends.
4. Clicking it when it is the only queued item changes nothing on screen at all — the list is reordered onto itself.
5. main.log shows the steer path being refused repeatedly and never escalating:
   [queue] steer requested → [queue] steer refused: no run → "accepted":false,"error":"No run in progress."

Steps to reproduce the issue

1. Desktop 0.1.57 on Windows, open any chat with a model that takes a while to start answering.
2. Send a prompt and, while the turn is running, send a second message so it is queued.
3. Hover the ↵ icon on the queued row — the tooltip reads 立即发送 / "Send now".
4. Click it. Observe that the message is neither injected into the running turn nor sent; with one queued item there is no visible change whatsoever.
5. Check %APPDATA%\Command Code\logs\main.log for [queue] steer requested / steer refused: no run entries.

Command Code Version

• Desktop app: 0.1.57 (resources/app/package.json → "version": "0.1.57")
• OS: Windows 11

Evidence from the shipped bundle (0.1.57)

Paths inside resources/app/out/:

a) The button's handler reorders only — renderer/assets/workspace-screen-*.js, sendQueuedMessageNow (exported as N):

const N = d.useCallback(I => {
  const _ = p.current.find(O => O.id === I);
  if (!_) return;
  f(O => O[0]?.id === I ? O : [_, ...O.filter(K => K.id !== I)]);   // move to front of queue only
  const $ = _.threadId, H = window.electronAPI.cancelSteeredMessage;
  if (!$ || typeof H != "function") return;
  // …un-steers the *other* queued items on this thread…
}, []);

There is no steerAgent call and no send/start-turn call in this handler.

b) The button label promises a send — same bundle, the queued-messages list:

s.jsx("button", {
  onClick: c => { c.stopPropagation(); r(a); },
  "aria-label": o("sendQueuedMessageNow", { defaultValue: "Send queued message now" }),
  title: o("sendNow", { defaultValue: "Send now" }),
  /* … */
})

c) The actual steer is a separate, silent effect — same bundle:

const _ = window.electronAPI.steerAgent;
if (typeof _ == "function") for (const $ of A.queue) {
  /* …guards: thread streaming, steerable content, no images… */
  const O = _(H, Bse($)).then(K => {
    On("steer answered", { id: $.id, ms: Date.now() - P, ...K });
    if (!K.accepted) return;      // ← silent: no notify, no retry, no fallback
    /* … */
  })
}

d) Why it is refused — main/index.js, steerAgentTurn:

function liveRunOwner(sessionId) {
  const context = sessionContexts.get(sessionId);
  const reservation = inFlightSessions.get(sessionId);
  return { live: Boolean(context?.activeRun) || reservation !== void 0, /* … */ };
}
function steerAgentTurn(sessionId, input, callerWebContentsId) {
  const { live, owner } = liveRunOwner(sessionId);
  if (!live) {
    trace("[queue] steer refused: no run", { sessionId, steerId: input.steerId });
    return { accepted: false, error: "No run in progress." };
  }
  /* … */
}

e) The idle-drain path cannot help either while the renderer believes the thread is busy — same bundle, the drain retry loop:

const moe = (e, t) => { /* … */
  const o = async () => {
    if (n || !t.isQueued(e.id)) return;
    if (await t.send(e)) { t.dequeue(e.id); return; }
    r += 1; i = window.setTimeout(() => void o(), r < 40 ? 150 : 1e3);   // unbounded
  };
};

and the send gate that makes t.send fail:

if (g.current.has(me.id)) {
  On("send refused: thread still has a run registered", { threadId: me.id, chars: Z.length });
  return false;
}

Prior art / related

• #46 — "[Feedback]: Improve queuing messages" (open, p2, assigned). Maintainer reply on 2026-09-07:

  "Send now not working: it moves the queued message to the front so it goes out when the current turn ends, it does not interrupt the turn."
  That reply settles the semantics, but the shipped label ("Send now" / 立即发送) and the missing feedback still describe a broken control rather than a reorder action.

• #897 — "Allow removing/canceling a queued message without interrupting the active run" — adjacent queue-UX work.

Suggested fix (optional)

1. Make the button do what it says. On click: if liveRunOwner(sessionId).live, call steerAgent for that item; otherwise start a turn (or drain it immediately). If you want to keep reorder-only behaviour, rename the tooltip to "Move to front" / “移到队首” and document it.
2. Never fail silently. In the steer effect, on accepted === false notify the user once per item ("No run in progress." → “当前没有运行中的任务，将在空闲后发送”) and re-arm the idle drain for that item.
3. Fallback, don't strand. If a steer is refused because no run exists, treat the item as a normal pending send instead of leaving it in a steered/limbo state.
4. Bound the drain. After N failed attempts, surface a retry/cancel action instead of retrying every 150 ms → 1 s forever.
5. Optional: only show the ↵ affordance when clicking it can actually change the outcome (e.g. hide/disable it when the queue has one item and no live run).

main.log
[2026-10-25 14:09:54.765] [info] [renderer] [queue] steer requested {"id":"cJ28lek8…","threadId":"15c73274…"}
[2026-10-25 14:09:54.767] [info] [queue] steer refused: no run {"sessionId":"15c73274…","steerId":"cJ28lek8…"}
[2026-10-25 14:09:54.897] [info] [renderer] [queue] steer answered {"id":"cJ28lek8…","ms":50,"accepted":false,"error":"No run in progress."}