Cue dashboard ignores agents with valid cue.yaml until they're opened in the UI

[scriptease]

Summary

The Cue dashboard's Sessions With Cue table does not list registered agents whose .maestro/cue.yaml is valid and present at the project root, when those agents have never been actively opened in the current Maestro process. The agent is a fully valid Cue host — its config parses, the file is readable, the agent is in the sessions store with the correct projectRoot — but no triggers ever fire and the agent is invisible in the modal. To the user, Cue silently does nothing for that agent.

Valid yaml open, the cue is the missing cue icon!

Repro

1. Have an agent registered in Maestro (visible in maestro-cli list agents) whose project directory has never been opened in the Maestro UI / has 0 historical sessions.
2. Place a valid .maestro/cue.yaml in that project root (e.g. one time.scheduled subscription is enough).
3. Open the Cue modal (Option+Q) → Sessions With Cue.
4. The agent does not appear, even after waiting through several poll intervals or scheduled times. No events are written to cue.db for that session ID.
5. Click the agent in Maestro's left sidebar to open a session (no need to send a message). Reopen the Cue modal → it now appears, and triggers begin firing.

Environment

• macOS, Maestro Desktop (current release)

• Cue enabled in Settings → Encore Features

• Agent in maestro-sessions.json with a valid projectRoot

• .maestro/cue.yaml exists at that root, parses, validates

• Verified file is readable by Node from that exact path:

  fs.existsSync('/path/with spaces and~tildes/.maestro/cue.yaml') // true

  (i.e. not a path-encoding issue with iCloud-style paths)

What I see in the source

• getSessions() reads from sessionsStore.get('sessions', []) and returns all 14 entries including the dormant agent (src/main/index.ts:458).
• CueEngine.start() iterates that list and calls sessionRuntimeService.initSession(session, …) for each (src/main/cue/cue-engine.ts:283).
• initSession does loadCueConfigDetailed(session.projectRoot) → in my repro this returns { ok: true, config } and should register the trigger sources.

So in theory the agent should appear after the next engine start. But it doesn't — it only appears once the agent is opened in the UI. Two plausible causes I couldn't fully nail down without running the binary in dev mode:

• A. Sessions added to the store after the engine started don't get picked up — there's no onSessionAdded listener that re-runs initSession for new entries. (My case: the agent existed before launch, so this would only apply if the store is read lazily somewhere.)
• B. The dashboard's Sessions With Cue listing is filtered to agents with an active runtime presence (open session / current process tab), even when the engine's registry has them. The actual triggers may also be gated on the same condition.

Either way the user-visible behavior is the same: a dormant agent silently drops its Cue config.

Expected

Any agent in the sessions store whose project root has a valid .maestro/cue.yaml should appear in Sessions With Cue and have its triggers running, regardless of whether its UI tab has ever been opened. That's how the docs read:

"Maestro automatically scans all your active agents for .maestro/cue.yaml files in their project roots."

A reasonable user reads "active agents" as "registered agents". The current behavior requires manually clicking each agent once to "warm" it before Cue does anything — which defeats the purpose of time.scheduled and task.pending for unattended agents.

Suggested fixes (any one helps)

1. UX fix — populate the dashboard from the engine's own registry (every session that initSession was called for), not from the UI's open-tab state. If initSession ran successfully, the agent should be visible.
2. Engine fix — if the cause is (A), add an onSessionAdded hook so newly-stored sessions get initSession without restart.
3. Visibility fix — even if a dormant agent is intentionally excluded, surface it as a dimmed row labelled e.g. "Inactive — open this agent to enable Cue" so users aren't left guessing why their config is silently ignored.
4. Docs fix — clarify that "active" means "currently/recently opened in the UI", and document the manual warm-up requirement.

Related

• task.pending: first-scan seeding never fires, even when tasks already exist #865 — task.pending first-scan seeding never fires (separate issue, found in the same investigation)