[Bug]: Desktop submit fails after /goal; local session row created but message never reaches backend

[antonstetner]

Bug Description

Hermes Desktop stopped submitting messages after I tried a /goal slash command. Discord gateway continues to work normally, but Desktop creates visible local/sidebar session rows and keeps/accepts typed input without committing the message to the backend session store.

Observed from local diagnostic:

• Desktop accepts text.
• Desktop shows a local session row such as test after desktop restart.
• Pressing Enter and clicking the Desktop Send button do not produce a response.
• After clicking Send, hermes sessions list does not show the Desktop test session.
• Discord gateway remains connected and this same agent can respond through Discord.

This appears Desktop-specific, likely in the slash/session submit path after /goal or post-update backend discovery/session bridge.

Steps to Reproduce

1. On Windows 10, update/run Hermes Desktop v0.18.2 (2026.7.7.2), upstream 7b5ba20.
2. In Hermes Desktop, attempt to use /goal.
3. After that, type a normal test message in Desktop, e.g. test after desktop restart.
4. Press Enter or click the Desktop Send button.
5. Observe Desktop creates/shows a local session row with that text.
6. Observe no assistant response appears in Desktop.
7. Run hermes sessions list.
8. Observe the Desktop test session/message is absent from the backend session store.
9. Send a message through Discord gateway and observe Discord still works normally.

Expected Behavior

Hermes Desktop should submit the message to the backend/session store, create or resume the correct session, stream the assistant response, and show the resulting session in hermes sessions list. Running /goal should not break later normal Desktop message submission.

Actual Behavior

Desktop appears to create/cache the local session row but the message never leaves the Desktop submit path. The composer accepts text, and the sidebar shows a session such as test after desktop restart, but there is no assistant response and no corresponding entry in hermes sessions list.

A direct UI Automation click on the Desktop Send button also failed to commit the message to the backend session store. Discord gateway remained healthy and continued receiving/responding normally.

Affected Component

Other

Messaging Platform (if gateway-related)

No response

Debug Report

Local debug report generated with `hermes debug share --local` rather than uploaded.

Key output:

version:          0.18.2 [7b5ba205] (2026-07-12)
os:               Windows 10 AMD64
python:           3.11.15
openai_sdk:       2.24.0
profile:          default
hermes_home:      ~/AppData\Local\hermes
model:            gpt-5.5
provider:         openai-codex
terminal:         local
gateway:          running (manual process, pid 27444)
platforms:        discord


Additional local evidence file: `C:\Users\Anton\AppData\Local\hermes\desktop-submit-failure-2026-07-12.md`

Operating System

Windows 10 AMD64

Python Version

3.11.15

Hermes Version

0.18.2 [7b5ba20] (2026-07-12)

Additional Logs / Traceback (optional)

Potential duplicate shown by GitHub: #43476 `bug(desktop): /goal swallows command — missing command.dispatch send+notice handler`.

I am filing because the observed failure is broader than simply swallowing `/goal`: later normal Desktop messages also appear not to commit to the backend session store.

Root Cause Analysis (optional)

Not confirmed. Likely related to Desktop handling of slash commands/session submit after /goal.

GitHub's duplicate detector suggests this may overlap with #43476: bug(desktop): /goal swallows command — missing command.dispatch send+notice handler.

This report may represent either the same issue or a remaining related failure mode: after /goal, Desktop creates a local/sidebar row but normal message submit does not reach the backend session store.

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR

[SHL0MS]

Found a reproducible mechanism for the '/goal then nothing reaches the backend' half of this, and #68776 fixes it.

The sequence: /goal runs slash.exec, and the backend sets the goal at that moment. The desktop then receives the send dispatch whose message is the kickoff prompt — but if busyRef is true when it lands, handleDispatch renders 'session busy — /interrupt the current turn before sending this command' and returns, discarding the kickoff. The goal now exists in the GoalManager state while the agent never hears about it, and follow-up turns look goal-unaware. On a fresh chat this also strands the session as 'Untitled session', since auto-title needs a completed exchange that never happens.

#68776 queues the kickoff on the composer queue instead of dropping it (sends on settle, visible in the queue panel meanwhile), plus fixes the /goal chip sealing (missing args:true) and the status header echoing the full goal text.

Note this is complementary to #63376, which addresses a different failure in the same flow (stale activeSessionId prop minting a second runtime session) — both can land.

[teknium1]

Fixed and closed — all three mechanisms behind this report are now on main.

This issue turned out to describe a flow with three independent failures, not one bug. Credit for untangling that goes to @SHL0MS (who isolated the third and correctly argued it was distinct rather than a duplicate) and @LeonSGP43 (who diagnosed the first):

#	Mechanism	Landed
1	stale activeSessionId prop minting a second runtime session	submit.ts:180 on main (originally #63376)
2	slash.ts and submit.ts resolving the target session differently, so a slash command could run against a session it had just created	#71605 · 584b274
3	the /goal kickoff being dropped when busyRef was true — goal set in GoalManager, agent never told	#71632 · 6b26b40 (salvage of #68776)

Both halves of the reported symptom are covered: the local session row no longer forks (2), and the message now reaches the backend instead of vanishing mid-turn (3). The 'Untitled session' side effect is fixed too — a slash on a fresh draft seeds the sidebar preview, since auto-title needs a completed exchange a bare command never produces.

Mechanism (2) was found from the other direction, while investigating why /goal status reported 'No active goal' for a live goal — same seam, opposite symptom.