Replying to cron job sessions doesn't work, redirects to start page

[gursuj]

Steps to reproduce:

1. In Settings > Preferences, enable Show non-WebUI sessions and Show cron sessions
2. Setup cron job
3. After job runs and shows up in chat, try replying to it. Instead of sending the message, this just redirects me to the new chat page

export-v20-717d.mp4

Might be due to how i setup the job? Here's the non-sensitive part of the prompt that triggers the cron:

[IMPORTANT: You are running as a scheduled cron job. DELIVERY: Your final response will be automatically delivered to the user — do NOT use send_message or try to deliver the output yourself. Just produce your report/output as your final response and the system handles the rest. SILENT: If there is genuinely nothing new to report, respond with exactly "[SILENT]" (nothing else) to suppress delivery. Never combine [SILENT] with content — either report your findings normally, or say [SILENT] and nothing more.]

Also some info on how the cron is set up:

• Deliver: origin (WebUI).
• Toast notifications: enabled (default for origin delivery).

[nesquena-hermes]

Thanks for the report and the video, @gursuj — this is a real bug, and it's the same root cause we're already tracking for foreign-origin (CLI/TUI/Desktop) sessions.

What's happening: a cron-job session is created agent-side and lives in state.db, but it has no WebUI JSON sidecar. The sidebar happily shows it (because GET /api/session synthesizes a read-only stub from state.db), but when you reply, POST /api/chat/start calls get_session(), which 404s on any session id without a WebUI sidecar. The client catches that 404 (static/messages.js:1236-1257) and falls back to the empty-state / new-chat path — which is exactly the "redirects to start page" symptom you're seeing. It's not your cron prompt; any non-WebUI-origin session hits this on reply.

Fix in flight: PR #3901 (api/routes: claim CLI/TUI/Desktop sessions on first POST) closes this asymmetry by routing both GET /api/session and POST /api/chat/start through one helper that claims/materializes a writeable session from state.db when it has recoverable messages. It's currently iterating on review feedback.

One thing we want to confirm so your case is definitely covered: PR #3901's claim path explicitly names CLI/TUI/Desktop/claude_code/gateway origins — we'll verify cron-origin sessions are included in that set (they should be, since they're state.db-backed agent sessions). Tracking this here and cross-linking to #3985 and PR #3901.

[sm2ee]

Hit this today with regular Hermes TUI sessions too, not just cron.

The session shows up and history loads fine, but replying bounces back to the empty start state. Logs show POST /api/chat/start returning 404 for a source_tag=tui, session_source=other row with no WebUI sidecar yet. So GET can synthesize/read it from state.db, but POST still goes straight through get_session() and misses it.

Local patch that fixed it for me:

• have chat/start materialize through _get_or_materialize_session() before _start_run
• treat non-WebUI state.db rows like tui as external in _isExternalSession() so the click path imports first

Verified with a real local TUI session: /api/session/import_cli materialized 129 messages. I did not run a real model turn. Looks like #3901 covers this; #3994/v0.51.363 fixed rename/move/update, but not this reply path.

[nesquena-hermes]

Thanks @sm2ee — your diagnosis matches what's on origin/master exactly, and the TUI case is the same root cause as the cron case in the original report.

Confirmed: chat/start still bypasses the materialize helper

The asymmetry you describe is real and current. _handle_chat_start resolves the session with a bare get_session() and 404s on anything without a WebUI sidecar (api/routes.py:12907-12911):

diag.stage("get_session") if diag else None
try:
    s = get_session(body["session_id"])
except KeyError:
    return bad(handler, "Session not found", 404)

Meanwhile the sibling POST handlers already route through the claim/materialize helper — rename/update at api/routes.py:7555, draft at 7746, archive at 8732 all call _get_or_materialize_session(body["session_id"]). So GET synthesizes a stub, rename/move/archive materialize a writeable sidecar, but the reply path alone still goes straight through get_session() and misses the state.db row. That's the inconsistency #3994/v0.51.363 left untouched.

The 404 then hits the client fallback at static/messages.js:1236, which strips the /session/<id> URL and resets to the empty state — exactly the "redirects to start page" symptom:

if(e&&e.status===404){
  try{ localStorage.removeItem('hermes-webui-session'); }catch(_){ }
  ... history.replaceState(null,'',_appRootPath()); ...
  S.session=null;S.messages=[];

Why your local patch is the right shape

_get_or_materialize_session (api/routes.py:1571) already does the heavy lifting: it tries get_session(), and on KeyError falls back to _lookup_cli_session_metadata + import_cli_session. Importantly for your case, a tui row is not treated as messaging — _is_messaging_session_record (api/routes.py:3171) only matches session_source == "messaging" or a known messaging source tag, so source_tag=tui/session_source=other rows fall through to the regular CLI/agent branch that imports full message history (consistent with your "materialized 129 messages" result). So routing chat/start through this helper before _start_run claims TUI/cron rows without tripping the read-only guard.

One caveat worth keeping in the fix: the helper raises PermissionError for read-only/messaging sessions, so chat/start should map that to a clear 403 ("read-only session") rather than letting it fall through to the same 404 path — otherwise messaging-origin sessions would still bounce to the start page with a misleading reason.

Status

This is tracked under PR #3901 (fix/webui-claim-cli-session, still open). Your TUI repro is good supporting evidence that the claim set needs to cover state.db rows generically (any non-WebUI source with recoverable messages), not just an explicit CLI/TUI/Desktop/cron allowlist — gating on source-tag membership risks missing session_source=other rows like yours. Cross-linking here so the reply path gets the same treatment GET already has.

[nesquena-hermes]

Root cause confirmed — this is the foreign-origin session write-path 404, not a problem with how your cron is set up.

Cron-job sessions live in the agent's state.db and have no WebUI JSON sidecar. GET /api/session synthesizes a read-only stub for them (so they show and are selectable in the sidebar once Show cron sessions is on), but the reply path POST /api/chat/start still calls bare get_session() on current master (api/routes.py _handle_chat_start), which raises KeyError → returns 404 Session not found for any session id without a sidecar. The client catches that 404 in static/messages.js:1236-1257 and falls back to the empty new-chat page — which is exactly the "redirects me to the new chat page" you're seeing. So the message isn't being dropped because of the prompt; the start route just can't find a writeable session.

This is the same class as the rename/move/workspace-switch "Session not found" reports. That mutation side already shipped (#3994 — materialize CLI sessions on rename/move/update). The reply / chat/start side is handled by #3901 (claim CLI/TUI/Desktop sessions on first POST), which routes both GET /api/session and POST /api/chat/start through one shared _claim_or_synthesize_cli_session() helper that materializes a real writeable session from state.db and saves it as a sidecar. #3901 is open and currently in review (changes-requested).

Cron sessions are state.db-backed agent sessions, so they should be covered by that same claim helper once #3901 lands — but cron isn't named explicitly in its stated claim set (CLI/TUI/Desktop/claude_code/gateway), so we'll confirm the cron source tag is included before closing this out. Tracking it against #3901; no separate fix needed.

[nesquena-hermes]

Fixed in v0.51.425 (Release OL) via #4219 (@TomBanksAU's #4211). Replying to cron-run sessions now works instead of redirecting to the start page.