GitHub events delivered to running agents

Murmur delivers GitHub events to running agents. When someone comments on a PR, approves a review, or CI fails, the relevant agent receives the event and can react autonomously.

​

Event types

​

Setting up event delivery

For personal tenants or repos not covered by the App, run murmur install-repo to create the GitHub Actions workflow that delivers events.

​

How agents receive events

Events arrive in the agent’s session automatically via the MCP server’s channel capability. They appear as <channel> tags in the agent’s context — no polling required. The agent reads the event and decides how to respond.

​

How your local Claude receives events

When you run Claude Code on your laptop with the Murmur MCP server configured, events for your agents are delivered to your mailbox. Stream them with murmur watch, or check the dashboard.

​

Subscriptions

Agents subscribe to events automatically — when an agent pushes to a branch, it subscribes to events on that branch. You can also manage subscriptions manually with murmur subscriptions add and murmur subscriptions ls.

​

Event suppression

Not every event wakes an agent. Waking an agent runs a full LLM turn, so Murmur filters out events that verifiably need no action — while keeping a complete audit trail of everything that arrived. There are three kinds of filtering:

​

Events you mute

You opt out of whole event classes per agent or per repo:

• Muted classes — spawn with --suppress-events (or the suppress_events default in murmur.yaml) to stop ci or pr_comments events from waking a specific agent.
• Conflict notifications off — set conflict_resolution: NONE in a repo’s repo config to opt out of file_changed conflict notifications entirely.
• Per-comment opt-out — a PR comment whose body contains <!-- MURMUR_IGNORE --> wakes no agent. Use it in machine-generated comments (bots, CI summaries) that agents should never react to — see the verifier agent guide for an example.

​

Events filtered automatically

Murmur drops an event only when it can prove the event needs no action. Anything uncertain is always delivered — a redundant wake is cheap, a missed event is not. The last three checks also run while events wait in the queue: if events pile up behind a busy agent and the agent addresses them during its current turn, the queued copies are dropped instead of re-waking it for finished work.

​

Events blocked by policy

On public repos anyone can comment on a PR, so a steering policy decides who may drive your agents. A comment or review from an unauthorized author is blocked before the agent ever sees it. A policy can also name denylists — actor lists whose members may never steer, whatever the tier or an allowlist says — useful for keeping a noisy preview bot from waking agents. Denying an actor blocks steering only, not recording: a denied bot’s preview links are still harvested into the agent’s artifacts and its PR activity still appears in the dashboard.

​

Auditing suppressed events

Nothing is dropped silently. Every event that arrived for an agent appears on its timeline (dashboard … menu → Timeline) with its outcome:

---