Skip to content

feat(desktop): show cron runs in Sessions by default - #71458

Open
dschnurbusch wants to merge 1 commit into
NousResearch:mainfrom
dschnurbusch:feat/desktop-cron-sessions-inbox
Open

feat(desktop): show cron runs in Sessions by default#71458
dschnurbusch wants to merge 1 commit into
NousResearch:mainfrom
dschnurbusch:feat/desktop-cron-sessions-inbox

Conversation

@dschnurbusch

Copy link
Copy Markdown
Contributor

Summary

  • Show cron-run sessions in the normal, time-grouped Sessions list by default.
  • Add a per-job Hide from Sessions / Show in Sessions control in both the sidebar Cron Jobs section and Master Cron.
  • Keep cron acquisition separate from ordinary recents so a cron burst cannot consume the ordinary-session fetch budget.
  • Persist opt-outs by profile and job ID, then filter the cron slice before applying the Sessions presentation limit.

Why default-visible?

Hermes currently optimizes for a valid concern: scheduled jobs can fire in bursts, and those runs should not drown out ordinary conversations. Keeping cron acquisition in its own bounded slice is the right architectural response to that concern.

Hiding every cron transcript behind the Cron Jobs submenu is not the right product default, though. In professional-service work, cron output is often closer to an employee's work queue than scheduler exhaust. A lawyer, accountant, consultant, or other human-in-the-loop operator may need to read the result, answer a question, correct course, or continue the session. For these workflows, the cron burst is not noise; it is the primary interaction surface. Reminder-style jobs make this especially clear: an agent may schedule a future re-check, and the resulting transcript is precisely what the user must notice.

When those runs are only discoverable by opening Cron Jobs and inspecting individual jobs, the user must remember that a result exists, remember or guess which job produced it, and search across what may be dozens or hundreds of jobs. There is currently no inbox-level notification that compensates for that hidden placement.

This PR treats cron output as first-class session work product while preserving control over noisy automation:

  • New and existing jobs are visible in Sessions by default, so reminders and human-in-the-loop work cannot silently disappear.
  • A noisy or fully autonomous job can be hidden with one eye toggle.
  • The preference applies to all runs from that job and is available from both places users manage cron work.
  • Acquisition remains separate, so visibility does not let cron activity starve ordinary session retrieval.

The default matters. An opt-in assumes the user knows in advance which agent-created jobs will later require interaction. An opt-out instead favors discoverability, then lets the user suppress automation that proves unhelpful in the inbox.

This builds on the time-based Sessions grouping already landed in #70822. Visible cron runs participate in the same chronology rather than creating another navigation silo.

Implementation

  • Continue fetching ordinary recents and cron runs as independent slices through the existing batched sidebar endpoint. Ordinary recents still explicitly exclude cron.
  • Cache the raw cron slice separately, apply archived/per-job visibility filters, then apply the current Sessions limit before merging for presentation.
  • Request the current Sessions limit for cron runs normally. If any job is hidden, request a bounded 500-row cron window so a prolific hidden job does not consume the visible page before filtering.
  • Merge ordinary and visible cron sessions by profile-qualified lineage identity, sort by started_at, and feed the result into the existing date-grouping renderer from Sidebar date dividers, growing pinned section, and opt-in stale-session auto-archive #70822.
  • Persist an opt-out array under hermes.desktop.cronJobsHiddenFromSessions.v1. Entries are collision-safe JSON tuples of [normalizedProfile, jobId]; malformed entries are ignored.
  • Recompute the visible list from cached rows immediately when an eye toggle changes. The toggle does not issue per-job run requests.
  • Carry explicit profile ownership only where this feature needs it: Cron acquisition, job controls, and opening a selected Cron run. Cron rows remain readable and resumable but do not expose legacy archive/delete actions whose ownership model is outside this PR.
  • Define Hide from Sessions narrowly as the ordinary time-grouped Sessions feed. Deliberately pinned runs and full-text Search keep their existing behavior.
  • Preserve the current Cron Blueprint catalog and creation paths unchanged.

The 500-row hidden-job window is intentionally bounded. It avoids a per-job request fanout or a new backend filtering API in this focused PR; reaching that cap is represented conservatively as N+ with the existing Load More affordance.

Test plan

  • Focused Desktop feature suite: 71 tests passed.
  • Full Desktop Vitest suite: 2,944 passed, 3 skipped.
  • Desktop typecheck passed.
  • Desktop lint passed with 0 errors (23 existing warnings).
  • Production Desktop build passed.
  • Python endpoint test and syntax check passed.
  • git diff --check passed before and after the cherry-pick.

Scope

This is a focused product PR extracted from the earlier experiment in #42294. It intentionally does not include that branch's broader profile/session identity audit or unrelated navigation changes.

Related PR #62247 keeps no_agent cron runs out of the sidebar while repairing their run history. This PR proposes the opposite product default for the Sessions feed, but preserves the same anti-starvation concern through a separate bounded cron slice and per-job opt-outs.

@alt-glitch alt-glitch added type/feature New feature or request P3 Low — cosmetic, nice to have comp/desktop Electron desktop app (apps/desktop/*) comp/cli CLI entry point, hermes_cli/, setup wizard comp/cron Cron scheduler and job management area/profiles Multi-profile isolation, HERMES_HOME scoping area/sessions Session lifecycle, resume, persistence, history needs-decision Awaiting maintainer decision before any implementation sweeper:risk-session-state Sweeper risk: may lose/corrupt/mis-associate session or context state labels Jul 25, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

This was generated by AI during triage.

Related: #39362 and #42294 covered earlier desktop cron-session filtering/inbox approaches. This PR has a distinct default-visible policy plus profile-qualified controls and API support, so it is not a duplicate. Maintainer input is needed on the Sessions default.

@teknium1

Copy link
Copy Markdown
Contributor

Thanks for the focused implementation and the profile-qualified handling.

Problems

  • The backend endpoint this PR edits has moved: current main defines the live sidebar route in hermes_cli/web_routers/profiles.py:196; hermes_cli/web_server.py:4707 now imports that router. The web_server.py hunk therefore needs to be ported to the router module before it can affect the live route.

Suggested changes

  • If maintainers select the default-visible policy, salvage the endpoint change in hermes_cli/web_routers/profiles.py and adapt the Desktop pagination work to current main's profiles_truncated session state (apps/desktop/src/store/session.ts:351-357).
  • Confirm the product default first: current main intentionally keeps cron runs in their own collapsed section (apps/desktop/src/store/layout.ts:174-177), following 628f9040df's anti-starvation design.

Automated hermes-sweeper review.

@teknium1 teknium1 added sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform labels Jul 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/profiles Multi-profile isolation, HERMES_HOME scoping area/sessions Session lifecycle, resume, persistence, history comp/cli CLI entry point, hermes_cli/, setup wizard comp/cron Cron scheduler and job management comp/desktop Electron desktop app (apps/desktop/*) needs-decision Awaiting maintainer decision before any implementation P3 Low — cosmetic, nice to have sweeper:blast-moderate Sweeper blast radius: moderate — a subsystem or single platform sweeper:risk-compatibility Sweeper risk: may break existing users, config, migrations, defaults, or upgrades sweeper:risk-session-state Sweeper risk: may lose/corrupt/mis-associate session or context state type/feature New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants