Mobile: delivered messages leave a permanent ghost "Queued" duplicate (host ledger balanced, cache at 0) #14641

Summary

On Orca Mobile (iOS), a message sent while the desktop agent is mid-turn renders twice: once as a normal delivered message, and again below it as a grey bubble labelled "Queued". The message is delivered and the agent acts on it — the grey duplicate is spurious. They accumulate, one per message sent while the agent is busy, and survive app restarts.

What makes this more than cosmetic noise

The queued state appears to be client-side and has no reconciliation path, so nothing on the host can clear it. Verified on the host while two ghost bubbles were visible on the phone:

1. The session's own queue ledger is balanced. Replaying queue-operation records from the Claude Code transcript for the affected session:

enqueue 11 · remove 9 · dequeue 2  → outstanding 0

2. queuedMessageCount in the host cache is 0 for that session.
~/Library/Application Support/orca/ai-vault/session-parse-cache.json → entries[i][1].session.queuedMessageCount == 0.

3. The two ghosted messages produced no queue-operation records at all. They were delivered directly, never enqueued host-side — yet the client still painted "Queued" on both. That points at optimistic client-side state that is only reconciled by a queue lifecycle event which, on this path, never occurs.

Related: stale queuedMessageCount in the parse cache

Separately, session-parse-cache.json accumulates nonzero queuedMessageCount values for sessions whose real ledger balances to 0 (observed: counts of 4, 1, 1 across three sessions). Because the value is cached rather than recomputed, it persists across app and phone restarts. Zeroing the file by hand does not stick — the running app rewrites it from memory.

Reading the desktop bundle, the count is derived by replaying records:

if (record.type === "queue-operation") {
  if (record.operation === "enqueue" && content.trim().length > 0) queuedMessageCount++;
  else if (record.operation === "remove" || record.operation === "dequeue") queuedMessageCount--;
}

If the cache is not invalidated when a session's records change, a count that goes stale stays stale. Recomputing on read, or invalidating on transcript mtime change, would fix that half.

Reproduction

1. Start an agent session on a desktop host; attach Orca Mobile to it.
2. Give the agent a long-running task so it is mid-turn.
3. From the phone, send a message while "Agent is working" is displayed.
4. The message is delivered and acted on; a grey "Queued" duplicate also appears and remains.
5. Repeat — one additional ghost per message. They persist across force-quit of the desktop app and across Orca restarts.

Environment

• Orca desktop 1.4.182, macOS 26.5.2, Apple Silicon
• Orca Mobile (iOS 26), phone connected over Orca Relay
• Agent: Claude Code

What would help

• Reconcile or expire client-side queued entries when the corresponding message is delivered through a non-queue path.
• Recompute queuedMessageCount when the session transcript changes, rather than trusting the cached value.