Route Hermes CLI agent events through the default session listener

[maxmilian]

Description

Hermes is already a recognized CLIAgent (command prefix hermes, display name, brand color, skill providers), and structured warp://cli-agent OSC 777 payloads with "agent":"hermes" already parse to CLIAgent::Hermes. But create_handler() in app/src/terminal/cli_agent_sessions/listener/mod.rs routed Hermes to None and is_agent_supported() didn't list it, so TerminalView::handle_cli_agent_notification() dropped every Hermes event at the support gate — no tab status badge, no notification mailbox entry.

This PR:

• Routes CLIAgent::Hermes to DefaultSessionListener, the same listen-only path Droid / Pi / OhMyPi / Auggie use (no install flow — we just listen, per the approach discussed on Add Hermes CLI-agent notification support #10001).
• Derives is_agent_supported() from create_handler(agent).is_some() so the two tables can't drift apart again. The previous hand-maintained list matched create_handler's Some arms exactly, so no other agent's behavior changes.

This builds on @DarkGenius's earlier PR #15665 (auto-closed by the stale bot, not rejected), and incorporates the review feedback left there: the support check is now derived from the handler table, and the regression test goes through the is_agent_supported gate instead of bypassing it. Thanks @DarkGenius for the original report and fix.

Linked Issue

Closes #15666

• The linked issue is labeled ready-to-spec or ready-to-implement.
• Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes).

Testing

Added hermes_structured_events_pass_support_gate_and_are_forwarded (listener mod_tests.rs): parses the exact prompt_submit / stop payloads from #15666 via parse_event, asserts the resolved agent is Hermes and passes is_agent_supported, then checks the Hermes handler forwards both events. It fails on master at the is_agent_supported assertion and passes with this change.

• cargo nextest run --no-fail-fast -p warp --lib cli_agent — 240/240 passed

• ./script/format --check — clean

• cargo clippy --workspace --all-targets --tests -- -D warnings — clean

• cargo clippy -p warp --all-targets --tests -- -D warnings — clean

• I have manually tested my changes locally with ./script/run

Screenshots / Videos

Local OSS build of this branch (./script/run). The repro sends the two payloads from the issue from one long-lived block (the CLI agent session is tied to the running block, so sending them from two separate commands ends the session in between):

printf '\033]777;notify;warp://cli-agent;{"v":1,"agent":"hermes","event":"prompt_submit","session_id":"s1","query":"test"}\007'; sleep 20; printf '\033]777;notify;warp://cli-agent;{"v":1,"agent":"hermes","event":"stop","session_id":"s1"}\007'; sleep 60

Before (master): both events are dropped at the support gate, so the tab keeps its plain shell state and nothing reaches the notification mailbox — the behavior described in #15666.

After — prompt_submit: the tab shows the Hermes badge in the in-progress state.

After — stop: the badge switches to success, the tab gets an unread dot, and the mailbox icon shows a new notification.

After — mailbox: the notification panel lists "Hermes completed — Task completed."

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

[warp-for-oss]

@maxmilian

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I reviewed this pull request and requested human review from: @bnavetta.

Comment /warp-agent-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[warp-for-oss]

Overview

This PR routes Hermes structured CLI-agent events through the existing default session listener and derives the support gate from handler availability to prevent future table drift. The added regression exercises the Hermes parse path, support gate, prompt_submit forwarding, and stop forwarding.

Concerns

• No blocking concerns found.
• No approved spec context was provided, so there were no spec commitments to compare against.
• Security pass: no new input trust boundary, secret handling, auth, or injection concern was introduced by this listener routing change.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /warp-agent-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[bnavetta]

Thanks and sorry for the delay!

[maxmilian]

Thanks for the review, @bnavetta — no worries at all!

Rebased onto current master to clear the conflict with #15999 (Muse support), which touched the same two spots in listener/mod.rs. Resolution: Muse and Hermes now both sit in the DefaultSessionListener arm, and because is_agent_supported() is derived from create_handler(...).is_some() in this PR, Muse's explicit entry in the old hand-written list is covered automatically. muse_is_supported_via_default_listener passes unchanged alongside the Hermes regression test (cargo test -p warp --lib terminal::cli_agent: 218/218), and the range-diff vs. the approved head differs only by that one Muse line.

The earlier Windows failure was shared_session::sharer::network::tests::test_reconnect_attempt_budget_exhaustion_finishes_session, which is unrelated to this change; that test file has since been updated on master (#16071), so the rebase should give it a clean run.