How to use OpenClaw in CI/CD without giving it the release button

Publication date: June 1, 2026. Sources checked: September 13, 2026.

CI/CD gives a team a useful sequence: change the code, run checks, then deploy an approved result. An assistant can help with each part without owning the sequence. If one OpenClaw session can edit a checkout, read a production credential, and call a deploy command, a failed test has become an authorization problem.

The useful question is where OpenClaw may add context and where the pipeline or a person must decide. This guide uses GitHub Actions as the concrete example. OpenClaw receives a small CI event, investigates it in an isolated agent, and prepares a handoff. GitHub owns protected branches, the production environment, and the final approval.

Start with separate authorities

Assign one owner to each irreversible step before writing a prompt. This is a proposed operating model:

A model's answer is not a pipeline status. A sentence saying that a test looks harmless should not satisfy a required check, and a successful OpenClaw turn should not satisfy a production review. Let the system that owns the resource decide about that resource.

Use OpenClaw as the pipeline's observer

OpenClaw has an HTTP hook surface for external services. Its inbound webhook reference documents POST /hooks/agent, a dedicated token, explicit agent selection, and isolated sessions. A request can set deliver: false to suppress a successful chat announcement, but that does not remove tools. Tool policy must still deny changes and outbound actions.

The CI system should send only the run identifier, commit SHA, conclusion, and a link. Do not give the observer a deployment token. If it needs logs, either send a bounded redacted excerpt from CI or use a separate read-only identity. Both choices extend the trust boundary and should be recorded.

The following illustrative adapter is a notification workflow, not a required test. If OpenClaw is unavailable, the code checks can still pass or fail on their own.

name: OpenClaw CI observer

on:
  workflow_run:
    workflows: ['test']
    types: [completed]

permissions:
  actions: read
  checks: read
  contents: read

jobs:
  notify:
    if: github.event.workflow_run.conclusion == 'success' || github.event.workflow_run.conclusion == 'failure'
    runs-on: ubuntu-latest
    continue-on-error: true
    steps:
      - name: Send a normalized event
        env:
          HOOK_URL: ${{ vars.OPENCLAW_HOOK_URL }}
          HOOK_TOKEN: ${{ secrets.OPENCLAW_HOOK_TOKEN }}
          RUN_ID: ${{ github.event.workflow_run.id }}
          RUN_URL: ${{ github.event.workflow_run.html_url }}
          CONCLUSION: ${{ github.event.workflow_run.conclusion }}
          SHA: ${{ github.event.workflow_run.head_sha }}
        run: |
          set -euo pipefail
          jq -n \
            --arg id "$RUN_ID" \
            --arg url "$RUN_URL" \
            --arg conclusion "$CONCLUSION" \
            --arg sha "$SHA" \
            '{
              name: "ci-completed",
              message: ("CI run " + $id + " finished with " + $conclusion + " for " + $sha + ". Review " + $url + ". Summarize evidence and propose next checks; do not edit, merge, deploy, or send external messages."),
              agentId: "ci-observer",
              sessionMode: "isolated",
              deliver: false
            }' |
          curl --fail-with-body --request POST "$HOOK_URL" \
            -H "Authorization: Bearer $HOOK_TOKEN" \
            -H "Content-Type: application/json" \
            -H "Idempotency-Key: ci-$RUN_ID" \
            --data-binary @-

GitHub's workflow syntax reference lets a workflow or job set each GITHUB_TOKEN scope to read, write, or none. Explicit permissions turn unspecified scopes into none. The observer therefore does not need contents: write, deployments: write, or pull-request write access.

Keep raw logs and commit messages out of shell syntax. The jq serializer keeps event fields as data. A log can contain test input, attacker-controlled text, or a secret printed by a failing command.

Give the observer less authority than the code agent

OpenClaw's tool-policy documentation says that a non-empty allow list blocks other tools and that deny rules win. It also warns that denying file tools does not make shell execution read-only. If exec remains available, a command can still write files or call a deploy client.

Start the observer with a read-oriented profile and verify it against the live schema for your installed version:

{
  hooks: {
    enabled: true,
    token: '<long-random-hook-token>',
    path: '/hooks',
    allowedAgentIds: ['ci-observer'],
    allowRequestSessionKey: false
  },
  agents: {
    entries: {
      'ci-observer': {
        tools: {
          allow: ['read', 'web_fetch'],
          deny: ['exec', 'write', 'edit', 'apply_patch', 'process', 'browser', 'gateway', 'cron', 'message']
        }
      }
    }
  }
}

The webhook documentation recommends a dedicated token, an allowed-agent list, and no caller-selected session key unless needed. It also says hook admission is not completion: HTTP success can mean that a run was admitted while the model is still preparing. Use the documented completion option or inspect the run record; do not make admission a quality gate.

A code-change agent has a different boundary. If it receives write, edit, or apply_patch, put it in a branch or disposable workspace with no production secrets. Keep gateway, cron, and outbound messaging out of that profile. The OpenClaw exec documentation says host execution can target the Gateway or a node and that relevant host paths may run without ordinary prompts. That is too broad a default for a code assistant whose change will be tested by CI.

If a local test needs host execution, make it a narrow exception. The exec-approvals guide describes deny, allowlist, and approval modes, per-agent allowlists, and deny fallbacks. It also warns that approvals reduce accidental execution risk; they are not per-user authentication or a read-only filesystem policy.

Keep the release job in GitHub

The production job should consume a known artifact, reference a protected environment, and carry only the permissions its deploy action needs. The hook token belongs in the observer workflow, not in the production environment.

jobs:
  deploy-production:
    needs: build
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment:
      name: production
    concurrency:
      group: production
      cancel-in-progress: false
    permissions:
      contents: read
      deployments: write
    steps:
      - name: Retrieve the approved artifact
        run: ./ci/fetch-approved-artifact.sh
      - name: Deploy
        run: ./ci/deploy-production.sh

This is a skeleton, not a deploy script. Pin third-party actions to a verified full-length commit SHA and review provider authentication. GitHub's secure-use guidance recommends least-privilege credentials and describes a full-length SHA as the immutable way to pin an action.

When a job references production, GitHub can hold it until protection rules pass. The deployment and environment reference documents required reviewers, branch or tag restrictions, and environment secrets that remain unavailable until approval. It also supports preventing the person who started a deployment from approving it. GitHub notes that required reviewers on Free, Pro, and Team plans are available only for public repositories; administrators can bypass protection by default unless that option is disabled.

Use concurrency for a resource that cannot safely receive two releases at once. GitHub's deployment controls documentation describes concurrency groups for keeping one deployment in progress for an environment. An OpenClaw response saying that two releases look compatible is not a substitute.

Do not confuse the four kinds of approval

GitHub's protected-branches documentation supports required reviews, code-owner reviews, and required status checks. It can also require a status from a specific app. Protect main and the workflow files that define deployment.

OpenClaw's approval path is useful when an agent is about to run a command on a Gateway or node. It is not a GitHub environment review. Keep those names separate in the runbook.

Test the seams, not just the happy path

The important tests are attempted crossings between authorities. These are proposed acceptance checks:

• Ask the observer to edit a file, run a shell command, create an automation, or send a message. Its tool policy should block the call.
• Send a hook with a wrong token, an unknown agentId, and a repeated idempotency key. The observer workflow should report the notification problem without changing the build result.
• Make a test job fail. The observer may summarize it, but the production job must remain unavailable through its normal dependency and branch conditions.
• Reject the production environment review. Confirm that the deploy command did not run and that environment secrets were not exposed to an earlier job.
• Change the workflow or deployment script. Confirm that the protected branch requires the intended reviewers and status checks.
• Stop the Gateway. Decide whether an unavailable observer is advisory or required. Do not let an implicit retry become an unreviewed deployment path.

Be careful with OpenClaw command payloads. The automation payload documentation says they run scripts on the Gateway host as an operator-admin surface rather than an agent tools.exec call, so model-visible exec policy does not govern them. Do not create a scheduled deploy-production command from a CI event. A scheduled read-only report is a different risk.

Run openclaw security audit before expanding authority. The audit checks reference calls out full host execution, exec enabled despite disabled filesystem tools, automatic skill allowlisting, and interpreter allowlists without strict inline-evaluation checks. A clean audit does not prove the release process is safe; a warning tells you which boundary needs a decision.

Acceptance criteria for the finished setup

• The code agent works in a non-production branch or workspace and cannot reach production credentials.
• The observer receives a bounded event with the SHA and run URL, uses an isolated session, and has no write, exec, deploy, or message authority.
• The protected branch requires the relevant reviews and status checks.
• Only the production job references the production environment and its credentials.
• The production environment requires a reviewer who cannot self-approve when that separation is required.
• The observer token is dedicated, stored as a secret, and absent from prompts, logs, and deployment steps.
• Gateway downtime, hook rejection, approval rejection, and workflow-file changes have a documented response.

OpenClaw fits best between a signal and a decision. It can turn a failed run into a compact investigation, move a code change toward a reviewable pull request, and prepare the information a release owner needs. The release button should remain a property of the CI system and its human gate.

Sources

1. Inbound webhooks - OpenClaw
2. Automation payloads - OpenClaw
3. Exec tool - OpenClaw
4. Exec approvals - OpenClaw
5. Sandbox vs tool policy vs elevated - OpenClaw
6. Security audit checks - OpenClaw
7. Deployments and environments - GitHub Docs
8. Deploying with GitHub Actions - GitHub Docs
9. Workflow syntax for GitHub Actions - GitHub Docs
10. Secure use reference - GitHub Docs
11. About protected branches - GitHub Docs