ElasticClaw

Open source workflow automation for coding agents.

ElasticClaw turns issue tracker events into governed coding workflows: start the right agent, provision an isolated workspace, inject the issue context, mint scoped GitHub credentials, open the PR, watch review and CI, and clean everything up when the work is done.

Remote coding agents give you a shell. ElasticClaw gives you the workflow around it.

Why ElasticClaw exists

AI coding agents are getting good enough to do real work, but real work does not begin with a prompt and end with a terminal transcript. It starts in Linear, GitHub Issues, Shortcut, webhooks, releases, customer escalations, dependency alerts, and private operational queues. It needs credentials with boundaries. It needs branch and PR policy. It needs logs, lifecycle state, review handling, CI awareness, and cleanup.

ElasticClaw is the control plane for that loop.

Instead of manually launching agents one at a time, you define workspaces and workflows: repeatable workstreams that know when to start, what access to grant, which model and tools are allowed, how to drive the PR, and when to tear the sandbox down.

What it does

• Workspaces define the runtime: repos, bootstrap files, instructions, environment, MCP servers, model defaults, and provider settings.
• Workflows define the automation: trigger rules, stages, issue movement, lifecycle policy, and cleanup.
• Scoped GitHub App credentials give each agent temporary repo access instead of broad personal tokens.
• Issue tracker integrations turn Linear, GitHub Issues, Shortcut, and webhook events into structured work.
• Sandbox providers run each agent in an isolated workspace using Daytona, Replicated CMX, or exe.dev.
• Single-binary ElasticClaw Server gives you the API, web UI, state, settings, and workflow automation in one self-hosted Go service.

Each running agent runs OpenClaw, connects back to ElasticClaw Server through the connector, clones the allowed repos, receives the issue context, and works inside an ephemeral VM.

The Workflow Loop

flowchart LR
    A[Issue or event] --> B{Factory filters}
    B -->|match| C[Workspace]
    C --> D[Sandbox]
    D --> E[Agent works]
    E --> F[Pull request]
    F --> G[CI and review]
    G --> H[Merge or close]
    H --> I[Cleanup]
    B -->|no match| J[Ignore]

ElasticClaw is designed for the work that should happen again and again:

• Bug lanes from Linear statuses
• Dependency update workflows
• Docs and migration queues
• Release follow-up tasks
• Customer escalation workflows
• Background work that should produce PRs, not meetings

Quick start

Install the CLI:

brew tap elasticclaw/elasticclaw
brew install elasticclaw

Prerelease builds publish a separate formula so stable installs stay on non-prerelease tags only:

brew install elasticclaw/elasticclaw/elasticclaw-beta

Deploy ElasticClaw Server to an Ubuntu VPS:

elasticclaw install \
  --server ssh://[email protected] \
  --domain server.mycompany.com \
  --ssh-key ~/.ssh/id_ed25519

Then configure the pieces your first workflow needs:

1. A sandbox provider such as Daytona, Replicated CMX, or exe.dev.
2. A GitHub App so ElasticClaw can mint scoped installation tokens.
3. A workspace that defines repos, instructions, tools, and model defaults.
4. An issue source such as Linear, GitHub Issues, Shortcut, or a webhook.
5. A workflow that ties the trigger, workspace access, and lifecycle together.

Watch the installation walkthrough: YouTube quick start.

Full setup guide: elasticclaw.ai/docs/installation

Linear workflow triggers

trigger.linear supports event, workspace, team, projects, states, labels, exclude_labels, assigned_to, and agent_status_error. When projects is omitted or empty, issues in any Linear project—including issues with no project—can match. Otherwise, an issue must belong to one of the listed project IDs or names.

trigger:
  linear:
    event: status_changed
    team: ADV
    projects:
      - Adversary Labs
    states:
      - Todo

See the Linear issue workflow example.

For deterministic plan approval (schema gate instead of freeform chat), see linear-issue-plan-gate.yaml and the docs on plan approval.

V1 stage triggers

A stage's message_contains trigger accepts a token at the start of a message line (leading whitespace and markdown decoration are allowed). Optional from restricts the trigger to the claw's current stage ID: use a string or a non-empty list of existing stage IDs. Omit from to preserve matching from any stage. Blank, unknown or non-string IDs are validation errors.

stages:
  - id: implementation
    entry: true
  - id: build_check
    triggers:
      - message_contains: "[IMPLEMENTATION_DONE]"
        from: implementation
      - message_contains: "[RETRY_BUILD]"
        from: fix_build
  - id: fix_build
    triggers:
      - gate_result: {stage: build_check, verdict: fail}
        from: build_check
  - id: finished
    terminal: true
    triggers:
      - message_contains: "[DONE]"
        from: build_check
  - id: blocked
    terminal: true
    triggers:
      - message_contains: "[BLOCKED]"
        from: [implementation, fix_build]

This is the beginning of the README. Read the rest at the original. Read the full README ↗