What resonate-bash is good at

resonate-bash is Resonate's MCP tool for running shell commands as durable, asynchronous tasks.

Using Claude Code? Follow the installation guide here: https://docs.resonatehq.io/get-started/claude-code

If you've ever had a coding agent sitting there burning context waiting for a CI run to finish, a deploy to come up, or DNS to propagate, you already know the shape of the problem. The wait itself is small — a poll loop, a status check. The agent doesn't need to see anything until the wait is over. But it's awake for every five-second tick, and the context window gets eaten alive by output it can't use.

That's the loop resonate-bash is built to get the agent out of. A few places it pays off most clearly:

→ Long-running polling loops.

Waiting for an external system to reach a state — a CI run finishes, a deploy goes live, DNS propagates, an image-generation job completes. The until X; sleep N; done loop runs in the shell, not in the model. The model is not invoked during the wait.

{
  "id": "ci-watch-2026-05-21",
  "script": "until gh run view 12345 --json status -q .status | grep -q completed; do sleep 60; done",
  "timeoutMs": 3600000
}

The agent doesn't watch the run. It hears about the run when it's done.

→ Operations that need to outlive the current session.

Promises live on the Resonate server, not in the calling Claude Code session. If the laptop closes, the host hiccups, or a new conversation starts tomorrow, the work continues. A later session can look up the promise ID and read the result.

→ Named, queryable state.

Promise IDs are first-class — prefix them by project and date (yourproject-ssl-watch-2026-05-21) and filter promise-search later via the tags parameter to audit what fired across days.

→ Fire-and-watch coordination with external systems.

Most CI tools, deploy platforms, image-generation APIs, and data-export jobs expose a status endpoint but no webhook. resonate-bash is the right shape for that: submit the work, poll in the shell, get notified on completion.

→ Composable with Resonate's promise primitives.

The same promise IDs work with promise-create, promise-listen, and promise-settle. A one-off script can be promoted into a multi-step durable workflow later without re-architecture.

→ Worth knowing.

One thing worth knowing before you reach for it: scripts are stored in the promise itself, and on a crash they restart from the top. That's what makes them durable. It also means you have to write them idempotently — anything that can't double-fire on retry needs a check-then-trigger guard, not a "trigger then poll" pattern. Once that's internalized it's barely a constraint; before, it's a foot-gun.