DEV Community: Olivier Buitelaar

MCP + Workflow Patterns: Orchestrating Complex CI Pipelines

Olivier Buitelaar — Mon, 06 Apr 2026 10:44:21 +0000

Last week, I shipped workflow-guardian — a GitHub Action that lints your CI/CD workflow files. But the real story isn't just validation; it's about orchestration patterns.

If you read my previous post on OpenClaw's MCP implementation, you know MCP shines when coordinating distributed agents. The same principles apply to GitHub Actions.

The Problem: Complexity Explosion

Modern CI/CD pipelines are complex. You have:

Matrix builds (multiple OS, Node versions)
Conditional jobs (run only on main branch, skip on docs)
Secrets & environments (different for staging/prod)
Orchestration (wait for tests before deploying)

This complexity leads to:

Silent failures (job runs when it shouldn't)
Race conditions (deploy before tests finish)
Security gaps (hardcoded secrets)

The Pattern: MCP-Inspired Constraints

Think of your GitHub Actions workflow as a distributed system. Each job is an agent. Jobs need:

Contract validation — Declare what each job expects
Message passing — Jobs communicate via outputs
Constraint enforcement — Prevent invalid states

This is exactly what workflow-guardian does.

Real Win: Catch Bugs Before They Ship

In production systems, we use this pattern. A colleague accidentally created a circular dependency in a deploy workflow. workflow-guardian caught it before merge.

The cost of catching that in CI vs. production: hours vs. incidents.

Next Steps

Add workflow-guardian to your repos: uses: ollieb89/workflow-guardian@v1
Start writing job contracts (explicit outputs)
Use conditional orchestration to enforce safe deployment sequences

Questions? Drop a comment.

How OpenClaw Implements MCP for Multi-Agent Orchestration

Olivier Buitelaar — Tue, 24 Mar 2026 17:57:28 +0000

How OpenClaw Implements MCP for Multi-Agent Orchestration

When you search for MCP orchestration today, the top results are Google ADK and Dynatrace — both solid tools for their respective niches. But they tell only part of the story. Google ADK is purpose-built for Google Cloud environments. Dynatrace approaches MCP from an observability angle. Neither gives you a self-hosted, multi-channel, multi-agent orchestration framework that treats MCP servers as native first-class tools with zero glue code.

That's what OpenClaw is.

OpenClaw is an open-source AI agent framework built around the idea that Model Context Protocol tools should just work — inside any agent, across any channel (Telegram, Discord, WhatsApp, Slack), without custom integration code. This guide walks through exactly how OpenClaw implements multi-agent MCP: the architecture, the practical setup, and how it compares to the alternatives.

What Is MCP (and Why It Matters for Multi-Agent Systems)?

Model Context Protocol (MCP) is an open standard that defines how AI agents discover and call external tools and data sources. It was introduced to solve the fragmentation problem: every tool integration used to require bespoke code. MCP standardises that surface.

MCP has three core primitives:

Tools — callable functions that agents invoke to take action (search the web, send an email, run a query)
Resources — structured data exposed by the server (files, database records, API responses)
Prompts — reusable prompt templates with parameterised inputs

For a multi-agent system, these primitives matter because they establish a shared tool interface. When every capability is described via MCP's self-describing schemas, agents can discover what's available, understand input/output contracts, and call tools without hardcoded bindings. You get plug-and-play capability composition across agents.

The problem is that most implementations stop here — they wire up a single agent to a single MCP server. Production multi-agent MCP orchestration requires more: routing tools to the right agents, managing sessions, controlling access, and coordinating across channels. That's the gap OpenClaw fills.

OpenClaw's MCP Architecture: Three Levels

OpenClaw integrates MCP at three distinct levels, each serving a different use case. Together they cover the full spectrum from broad app integrations to targeted browser automation.

Level 1: Plugin-Level MCP Clients

The primary integration point is OpenClaw's plugin system. Plugins are npm packages that connect to MCP servers at startup and register their tools as native agent tools inside the OpenClaw gateway. From the agent's perspective, an MCP tool looks identical to a built-in tool — no distinction, no extra configuration per call.

The Composio plugin is the canonical example. It connects to https://connect.composio.dev/mcp and registers 500+ app integrations — Gmail, Slack, GitHub, Notion, Google Workspace, and more — directly into the agent tool registry.

Plugin configuration lives in openclaw.json under plugins.entries:

{
  "plugins": {
    "entries": [
      {
        "package": "@composio/openclaw-plugin",
        "config": {
          "apiKey": "${COMPOSIO_API_KEY}",
          "mcpEndpoint": "https://connect.composio.dev/mcp"
        }
      }
    ]
  }
}

Notice the ${COMPOSIO_API_KEY} syntax — OpenClaw interpolates environment variables directly in config, keeping secrets out of version control.

When the gateway starts, the plugin connects to the MCP server, fetches the tool manifest, and registers each tool. Agents can then call GMAIL_SEND_EMAIL or GITHUB_CREATE_ISSUE exactly as they would any native capability.

Level 2: Skill-Level MCP via mcporter

Not every MCP integration warrants a full plugin. For direct, CLI-level access to any MCP server, OpenClaw includes mcporter — a built-in skill that exposes MCP servers as command-line tools.

Core mcporter commands:

# List all tools available on a connected MCP server
mcporter list

# Call a specific tool with key=value arguments
mcporter call server.tool_name key=value key2=value2

mcporter supports all three MCP transport protocols:

Stdio — for local MCP servers spawned as subprocesses
SSE (Server-Sent Events) — for remote HTTP-based MCP servers
WebSocket — for persistent bidirectional connections

This makes mcporter the right tool when you want to test an MCP server before writing a plugin, script one-off MCP calls, or integrate a niche server that doesn't have a dedicated OpenClaw plugin yet.

Level 3: Browser MCP Integration

OpenClaw ships with Chrome DevTools MCP integration for browser automation. Activate it with:

openclaw browser --mode user

This connects the Chrome DevTools Protocol via MCP, giving agents the ability to automate browser interactions — navigation, form filling, screenshot capture, DOM inspection — through the same MCP tool interface used everywhere else.

Practical Walkthrough: Adding MCP Tools to Your Agents

Here's the end-to-end flow for wiring a new MCP server into your OpenClaw setup.

Step 1: Install the Plugin

openclaw plugins install @scope/your-mcp-plugin

OpenClaw validates the plugin manifest and runs install with --ignore-scripts by default for security. You can override this explicitly if needed, but the safe default prevents supply-chain script injection.

Step 2: Configure in openclaw.json

Add the plugin entry with any required config. Use ${ENV_VAR} for secrets:

{
  "plugins": {
    "entries": [
      {
        "package": "@scope/your-mcp-plugin",
        "config": {
          "endpoint": "https://your-mcp-server.example.com",
          "apiKey": "${YOUR_API_KEY}"
        }
      }
    ]
  }
}

Step 3: Control Per-Agent Tool Access

This is where OpenClaw's multi-agent MCP orchestration shines. You don't have to expose every MCP tool to every agent. Use allowlists in agents.list[].tools.allow:

{
  "agents": {
    "list": [
      {
        "id": "content-agent",
        "tools": {
          "allow": ["GMAIL_SEND_EMAIL", "NOTION_CREATE_PAGE", "GITHUB_CREATE_ISSUE"]
        }
      },
      {
        "id": "ops-agent",
        "tools": {
          "allow": ["SLACK_SEND_MESSAGE", "GITHUB_LIST_ISSUES", "GITHUB_UPDATE_ISSUE"]
        }
      }
    ]
  }
}

Each agent only sees — and can only call — the tools explicitly allowed for it. This is how you implement least-privilege access across a multi-agent system without per-agent plugin configuration.

Step 4: Use — Transparently

Once configured, agents call MCP tools exactly like any other capability. There's no special syntax, no MCP-specific client code in your agent logic. The OpenClaw gateway handles the MCP protocol layer entirely.

For direct CLI access, use mcporter:

mcporter call gmail.send_email to="team@example.com" subject="Deploy complete" body="v2.1.0 is live."

OpenClaw vs Generic MCP Client

If you're evaluating whether to use OpenClaw or wire up your own MCP client directly, here's the honest comparison:

Capability	Generic MCP Client	OpenClaw
MCP tool execution	Yes	Yes
Multi-agent tool routing	Manual	Built-in allowlists
Persistent gateway daemon	No	Always-on session management
Multi-channel delivery	No	Telegram, Discord, WhatsApp, Slack
Hierarchical orchestration	No	Parent/child session model
Plugin security	No	Manifest validation + ignore-scripts
Scheduled MCP tool runs	No	Cron integration
Tool sandboxing	No	Configurable exec security
IDE integration (ACP)	No	ACP bridge for Codex, Claude Code

A generic MCP client gives you the protocol. OpenClaw gives you the orchestration layer built on top of it.

How OpenClaw Compares to Google ADK and Dynatrace

Google ADK

Google's Agent Development Kit has solid MCP support and integrates cleanly with the Google Cloud ecosystem — Vertex AI, Cloud Run, BigQuery. If you're building agents that live entirely within GCP, ADK is a reasonable choice.

The limitation is vendor lock-in. ADK assumes Google Cloud infrastructure. You can't run it locally on a laptop with your own gateway daemon, route messages through Telegram, or manage a mixed fleet of agents across channels without significant custom work. OpenClaw runs wherever Node.js runs — local, VPS, or cloud — with no infrastructure dependency.

Dynatrace

Dynatrace's MCP integration is primarily observability-oriented. Their angle is using MCP to let AI agents query monitoring data, trigger workflows, and surface insights from their platform. It's genuinely useful if you're already deep in the Dynatrace ecosystem and want AI-driven ops.

But Dynatrace is not an orchestration framework. It doesn't manage agent sessions, route tools across agents, or provide a programmable multi-agent backbone. OpenClaw approaches the same MCP standard from the orchestration angle — the question isn't "how do I query my observability platform via MCP?" but "how do I wire 500 different tools into a production multi-agent system and control which agent can call what?"

Different problems. OpenClaw solves the orchestration one.

Building Your Own MCP Server for OpenClaw

The MCP ecosystem grows through community-built servers. If you have a service or capability you want to expose to OpenClaw agents, here's the structure:

my-mcp-server/
├── package.json
├── src/
│   ├── index.ts          # MCP server entry point
│   ├── tools/            # Tool definitions
│   │   ├── create.ts
│   │   ├── read.ts
│   │   └── update.ts
│   └── resources/        # Resource definitions (optional)
└── README.md

Design principles for OpenClaw-compatible MCP servers:

Action-oriented names: create_issue, send_message, fetch_record — not vague like process or handle
Single purpose per tool: one tool does one thing; composition happens at the agent layer
Complete schemas: every input and output field described; agents use these to reason about tool usage
Structured output: return JSON objects, not unstructured strings; agents parse structured responses reliably
Env-based config: secrets via environment variables, never hardcoded; document required vars in README

Publish via npm. Once published, your server is discoverable through ClawHub (available as of v2026.3.22), OpenClaw's community registry for plugins and MCP servers.

# Install your published MCP server as an OpenClaw plugin
openclaw plugins install my-mcp-server

Getting Started

If you want OpenClaw MCP orchestration running today:

1. Install OpenClaw

npm install -g openclaw
openclaw init

2. Enable the Composio plugin for 500+ app integrations out of the box:

openclaw plugins install @composio/openclaw-plugin

Then add your COMPOSIO_API_KEY to your environment and configure the plugin entry in openclaw.json.

3. Enable mcporter for direct CLI MCP access — it's a built-in skill, enabled by default. Run mcporter list after connecting a server to see available tools.

4. Build your own MCP server — follow the structure above, publish to npm, and list it on ClawHub.

Resources:

GitHub: https://github.com/openclaw/openclaw
Docs: https://docs.openclaw.ai
Discord: https://discord.com/invite/clawd
ClawHub: https://clawhub.com

The multi-agent MCP future isn't locked to any cloud vendor. It runs wherever your agents run.

`pull_request_target` Without Regret: Secure Fork PRs in GitHub Actions

Olivier Buitelaar — Sat, 21 Mar 2026 19:02:35 +0000

`pull_request_target` Without Regret: Secure Fork PRs in GitHub Actions

If you maintain a public repo, you eventually hit this tradeoff:

You want CI + automation on contributions from forks.
You don’t want to leak secrets or run untrusted code with elevated permissions.

A lot of teams switch to pull_request_target to get access to secrets and write permissions (for labels/comments), then accidentally check out and execute fork code in the same job. That’s one of the fastest ways to create a supply-chain incident in your own repo.

In this post, I’ll show a safer pattern I use in real repos:

Split untrusted validation from trusted automation.
Avoid checking out attacker-controlled code in privileged contexts.
Use explicit permissions and OIDC (where relevant).
Add guardrails so regressions are caught automatically.

Why `pull_request_target` is risky

pull_request_target runs in the context of the base repository, not the fork. That means it can access repo secrets and can get elevated GITHUB_TOKEN permissions.

That’s useful for trusted tasks like labeling, but dangerous if your workflow does this:

on:
  pull_request_target:
    types: [opened, synchronize]

jobs:
  bad-example:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - run: npm ci && npm test

This checks out untrusted fork code and executes it inside a privileged event context.

Even if you think “it’s just tests,” test scripts can run arbitrary shell commands, exfiltrate tokens, or abuse write permissions.

The safer architecture: two workflows

Use:

pull_request for untrusted code execution (no secrets, minimal token permissions)
pull_request_target for trusted metadata actions only (labels, comments, triage)

Workflow A: untrusted CI (`pull_request`)

This workflow can build/test fork code, but should have minimal permissions and no secrets.

# .github/workflows/pr-ci.yml
name: PR CI (untrusted)

on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout PR code
        uses: actions/checkout@v4

      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: npm

      - name: Install deps
        run: npm ci

      - name: Run tests
        run: npm test -- --ci

Key point: this is where untrusted code runs.

Workflow B: trusted repo automation (`pull_request_target`)

This workflow should not execute PR code. It should work only with event metadata.

# .github/workflows/pr-triage.yml
name: PR Triage (trusted)

on:
  pull_request_target:
    types: [opened, reopened]

permissions:
  contents: read
  pull-requests: write

jobs:
  label-size:
    runs-on: ubuntu-latest
    steps:
      - name: Add size label based on files changed
        uses: ollieb89/pr-size-labeler@v1
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}

No checkout of head.sha, no running contributor scripts, no package install from the PR branch.

If you must run privileged follow-up after CI

Sometimes you need a trusted action after untrusted checks pass (for example, posting a summary comment or syncing metadata). Use workflow_run as a boundary.

# .github/workflows/pr-post-ci.yml
name: PR Post-CI (trusted follow-up)

on:
  workflow_run:
    workflows: ["PR CI (untrusted)"]
    types: [completed]

permissions:
  contents: read
  pull-requests: write

jobs:
  comment:
    if: >-
      github.event.workflow_run.conclusion == 'success'
    runs-on: ubuntu-latest
    steps:
      - name: Comment on PR safely
        uses: actions/github-script@v7
        with:
          script: |
            const run = context.payload.workflow_run;
            const prs = run.pull_requests || [];
            if (!prs.length) return;
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: prs[0].number,
              body: '✅ CI passed. Maintainers can review safely.'
            });

This avoids executing untrusted code in the trusted phase.

Permission hardening checklist

Even with split workflows, tighten defaults:

Set explicit permissions in every workflow (don’t rely on defaults).
Prefer contents: read and add write scopes only when required.
Avoid long-lived cloud keys in secrets; prefer OIDC short-lived credentials.
Pin third-party actions to a commit SHA where possible.
Restrict pull_request_target workflows to metadata operations.

Example of pinning:

- name: Checkout
  uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

Catch bad patterns automatically

This is where linting/policy checks help. You want CI to fail if someone introduces dangerous patterns like:

pull_request_target + checkout of github.event.pull_request.head.sha
broad write permissions in untrusted workflows
unpinned external actions

A practical approach is to add a dedicated workflow policy step.

name: Workflow Policy

on:
  pull_request:
    paths:
      - '.github/workflows/**'

permissions:
  contents: read

jobs:
  policy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Validate workflow security
        uses: ollieb89/workflow-guardian@v1
        with:
          fail_on: high

If your org has custom requirements, encode them once and enforce them on every PR instead of relying on manual review memory.

Common “almost safe” mistakes

I still see these in otherwise good repos:

Using pull_request_target for tests because “we needed secrets quickly.”
Checking out head.sha in trusted workflows to parse files.
Default token permissions left too broad.
Comment bots with repo write access that also run shell commands from PR input.

If you recognize one of these, the fix is usually architectural, not just another if: condition.

A practical baseline you can adopt today

If you only do three things this week, do these:

Move all fork code execution to pull_request.
Keep pull_request_target metadata-only.
Add a workflow policy check to prevent regressions.

That gives you a strong baseline without slowing contributor velocity.

Toolkit links

If you want to implement this pattern quickly, these are the actions I use:

workflow-guardian (workflow policy/security checks): https://github.com/marketplace/actions/workflow-guardian
pr-size-labeler (safe PR size labeling): https://github.com/ollieb89/pr-size-labeler
stale-branch-cleaner: https://github.com/ollieb89/stale-branch-cleaner
changelog-generator: https://github.com/ollieb89/changelog-generator
test-results-reporter: https://github.com/ollieb89/test-results-reporter

If you’re maintaining public repos, treat workflow design like production code. The event model and permission boundaries matter as much as the scripts themselves.

Stop Ghosting Your Own Repos: Automate Stale Branch Cleanup with GitHub Actions

Olivier Buitelaar — Sat, 21 Mar 2026 13:02:07 +0000

Stop Ghosting Your Own Repos: Automate Stale Branch Cleanup with GitHub Actions

You know the feeling. You run git branch -a and a wall of text scrolls past. Most of those branches are "temporary" fixes from 2024. Some are features that were merged months ago but never deleted. A few are experiments that died a quiet death.

Leaving stale branches lying around isn't just "messy." It slows down your team, makes it harder to find what's actually active, and creates a mental tax every time you look at your repository.

In this guide, I'll show you how to automate the audit and cleanup of stale branches using GitHub Actions, so you never have to manually "clean house" again.

The Problem with Manual Cleanup

Most developers treat branch cleanup like doing the dishes: they wait until the pile is so high they can't ignore it anymore. Then someone spends an hour guessing which branches are safe to delete, occasionally deleting something important by mistake, and inevitably missing half the mess.

The issues with manual cleanup are clear:

It's inconsistent. It only happens when someone gets annoyed enough.
It's risky. Without a clear record of when a branch was last touched, you're guessing.
It's boring. No one wants to spend their Friday afternoon running git branch -D.

Automating the Audit

The first step in a safe cleanup process isn't deletion—it's visibility. You need to know which branches are stale before they disappear.

We can use a GitHub Action to scan the repository for branches that haven't seen a commit in a specific number of days (e.g., 90 days). Instead of deleting them immediately, the action should create a report.

Here is a basic implementation strategy using a custom GitHub Action I built called stale-branch-cleaner.

Step 1: Create the Cleanup Workflow

Create a file at .github/workflows/stale-branches.yml:

name: Stale Branch Audit
on:
  schedule:
    - cron: '0 9 * * 1'  # Run every Monday at 9:00 AM
  workflow_dispatch:      # Allow manual triggering

jobs:
  audit:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      issues: write
    steps:
      - name: Check for stale branches
        uses: ollieb89/stale-branch-cleaner@v1
        with:
          stale-days: '90'
          dry-run: 'true'      # Important: report only, don't delete yet
          create-issue: 'true'  # Create a GitHub Issue with the results

Step 2: Review the Report

When this workflow runs, it won't touch your code. Instead, it will open a GitHub Issue that looks like this:

Title: 🧹 Stale Branch Report (2026-03-21)
Body:
The following branches have had no activity for over 90 days:

Branch	Last Commit	Author
`feature/old-ui-experiment`	2024-11-12	@dev-alpha
`fix/temp-patch-v1`	2025-01-05	@dev-beta
`refactor/removed-module`	2024-09-30	@dev-alpha

Total stale branches found: 3.

Moving to Auto-Deletion

Once you've run the audit for a few weeks and you're confident in the results, you can move to a "soft delete" or a full auto-cleanup.

The "Safe" Auto-Delete Pattern

I recommend a 90-day stale window with a "dry run" period of one month. This gives everyone on the team a chance to see the issue and "rescue" any branch they still care about (by simply pushing a dummy commit or re-labeling it).

To enable auto-deletion, update your workflow:

- name: Cleanup stale branches
  uses: ollieb89/stale-branch-cleaner@v1
  with:
    stale-days: '120'    # Older branches only
    dry-run: 'false'     # This will actually delete branches!
    create-issue: 'true' # Still create an issue to log what was removed

Protecting Important Branches

Not all "inactive" branches are stale. You might have long-lived release branches, hotfix branches, or documentation branches that shouldn't be touched even if they haven't moved in 6 months.

The stale-branch-cleaner action automatically protects:

main
master
develop
Any branch matching release/*
Any branch matching hotfix/*

You can also provide a custom ignore list:

with:
  stale-days: '90'
  ignore-branches: 'archive/*,legacy-v1,important-refactor'

Why This Matters for DevOps

Clean repositories lead to clean CI/CD.

Faster clones: Fewer refs to fetch when running shallow clones.
Clearer visibility: Your branch dropdown only shows work that is actually happening.
Lower security risk: Old branches often contain outdated dependencies with known vulnerabilities that might accidentally get merged or deployed.

Conclusion

Stop letting "temporary" branches become permanent fixtures of your repository. Automating the cleanup process turns a manual chore into a background process that keeps your development environment sharp and professional.

If you want to try this out, the tool is open source and available on GitHub:

stale-branch-cleaner — Automates the audit and deletion of stale branches.

Part of the GitHub Actions Toolkit

I'm building a suite of tools to make GitHub Actions more manageable for developers:

workflow-guardian — Lints your workflows for security and best practices.
test-results-reporter — Aggregates all your test results into a single PR comment.
pr-size-labeler — Auto-labels PRs by size to improve review quality.

Give them a star if they help your workflow!

I launched 3 small products to make CI debugging less chaotic

Olivier Buitelaar — Sat, 21 Mar 2026 05:11:09 +0000

If you work with GitHub Actions long enough, you start seeing the same pattern:

A workflow fails.
Someone opens the logs.
A few guesses get tested.
The job gets rerun.
Eventually it goes green.
And almost nobody writes down the real root cause clearly.

That means teams lose time twice:

when the workflow breaks
when the same class of failure comes back later

So I made 3 small products to make CI debugging more structured.

1) GitHub Actions Triage Checklist

This is a practical checklist for diagnosing failed GitHub Actions runs faster.

It walks through common failure categories like:

triggers
branch and path filters
permissions
secrets and tokens
dependency issues
cache problems
runner issues
action version changes
concurrency conflicts

The goal is simple: stop guessing and work through the likely causes in a repeatable order.

Link:
GitHub Actions Triage Checklist

2) CI Debugging Template

This is a lightweight template for documenting CI failures properly.

It helps you:

capture what failed
record the exact error
test hypotheses
confirm root cause
document the fix
note prevention steps

It's meant to be simple enough to use during a real incident, but structured enough to make the debugging session actually useful afterward.

Link:
CI Debugging Template

3) CI Failure Recovery Pack

This bundle combines both products.

The idea is straightforward:

use the checklist to find the issue faster
use the template to document the fix and reduce repeat failures

If you're regularly dealing with broken workflows, the bundle is probably the best buy.

Link:
CI Failure Recovery Pack

Pricing

GitHub Actions Triage Checklist — $7
CI Debugging Template — $9
CI Failure Recovery Pack — $12

Who they're for

developers using GitHub Actions
DevOps and platform engineers
freelancers and consultants managing repos
small teams without a formal CI troubleshooting process

They're not meant to be flashy. They're meant to be useful.

Why I made them

A lot of CI debugging pain isn't some deep technical mystery.

It's often just:

noisy logs
no structured triage process
poor documentation after the fact
repeated failures no one captured properly

I wanted a simple way to make that workflow cleaner.

If you've built or bought similar developer products, I'd love feedback on the positioning, packaging, or what would make these more useful in practice.

If broken CI workflows are eating your time, these should help:
CI Failure Recovery Pack

GitHub Actions Security Checklist: 12 Things to Audit Before You Ship

Olivier Buitelaar — Sat, 21 Mar 2026 03:23:04 +0000

GitHub Actions Security Checklist: 12 Things to Audit Before You Ship

GitHub Actions is powerful — and that power cuts both ways. A misconfigured workflow can leak secrets, allow unauthorized code execution, or let attackers pivot into your production environment.

Here's the checklist I run through before shipping any workflow.

1. Pin third-party actions to a full commit SHA

# ❌ Dangerous — tag can be moved
- uses: actions/checkout@v4

# ✅ Safe — immutable
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

Tags are mutable. An attacker who compromises an upstream action repo can push a new commit to the v4 tag. Pinning to a SHA means you get exactly what you audited.

Tool that catches this: workflow-guardian flags unpinned actions automatically.

2. Never use `pull_request_target` without extreme caution

pull_request_target runs with write permissions and access to secrets — even for PRs from forks. Combined with actions/checkout on the PR head, you have a critical vulnerability:

# ❌ Pwn request pattern — DO NOT DO THIS
on: pull_request_target
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - run: npm install && npm test  # attacker controls this code

If you need pull_request_target, never check out or execute code from the PR branch.

3. Limit `GITHUB_TOKEN` permissions

Default token permissions vary by org settings. Be explicit:

permissions:
  contents: read        # only what you need
  pull-requests: write  # if you post PR comments

Or lock everything down at the workflow level and grant up per-job:

permissions: read-all  # workflow default
jobs:
  deploy:
    permissions:
      contents: write  # only this job gets write

4. Don't echo untrusted input into $GITHUB_ENV or $GITHUB_OUTPUT

This is an environment variable injection vector:

# ❌ Dangerous if PR title contains shell metacharacters
- run: echo "BRANCH=${{ github.event.pull_request.title }}" >> $GITHUB_ENV

# ✅ Use an intermediate env var
- run: echo "BRANCH=$TITLE" >> $GITHUB_ENV
  env:
    TITLE: ${{ github.event.pull_request.title }}

5. Validate workflow syntax before merge

Broken workflows fail silently or at the worst moment. Lint them:

- name: Lint workflows
  uses: ollieb89/workflow-guardian@v1

This catches syntax errors, deprecated features, and security anti-patterns before they hit main.

6. Don't store secrets in workflow files

Obvious, but it happens:

# ❌ Never do this
env:
  API_KEY: sk-prod-abc123xyz

# ✅ Use GitHub Secrets
env:
  API_KEY: ${{ secrets.API_KEY }}

Audit your repo history too — git log -S 'sk-' --all can surface old leaks.

7. Restrict who can trigger `workflow_dispatch`

Anyone with write access can trigger manual workflows by default. If your dispatch workflow deploys to production, add an environment with required reviewers.

8. Use environments for production deployments

jobs:
  deploy:
    environment: production  # requires approval from configured reviewers

Environments give you deployment protection rules, required reviewers, and scoped secrets.

9. Check for script injection in `run` steps

Any expression interpolated directly into a run block is a script injection risk:

# ❌ Vulnerable to script injection
- run: echo "PR author is ${{ github.event.pull_request.user.login }}"

# ✅ Use env vars
- run: echo "PR author is $AUTHOR"
  env:
    AUTHOR: ${{ github.event.pull_request.user.login }}

10. Don't use self-hosted runners for public repos

Anyone can fork a public repo and submit a PR that runs on your self-hosted runner. Unless you have strict protections in place, use GitHub-hosted runners for public repos.

11. Rotate secrets regularly and audit access

Check Settings > Secrets for stale/unused entries
Rotate any secret that may have been exposed in logs
Grep your workflow run logs for accidental secret prints: *** masking doesn't catch every format

12. Enable Dependabot for action version updates

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: weekly

This keeps your pinned actions updated with security patches automatically.

Automate as Much as Possible

This checklist is a lot to remember. Most of it can be caught automatically:

workflow-guardian — lints your workflow files on every PR, catching security issues and syntax errors before they merge
actionlint — static analysis for workflow syntax
Dependabot — keeps action versions current

The goal isn't to memorize all of this — it's to build the guardrails so you don't have to.

Found this useful? I build open-source tools for GitHub Actions security. Check out workflow-guardian — it automates most of this checklist.

workflow-guardian vs actionlint: A Technical Deep Dive

Olivier Buitelaar — Sat, 21 Mar 2026 00:12:10 +0000

Related articles:

Tools mentioned:

actionlint — Syntax and semantics validation
workflow-guardian — Security and best practices
test-results-reporter — Test aggregation

Getting Started with workflow-guardian in 5 Minutes

Olivier Buitelaar — Sat, 21 Mar 2026 00:05:34 +0000

Related tools:

workflow-guardian — CI/CD safety checks
test-results-reporter — Aggregate test results in PR comments
pr-size-labeler — Auto-label PRs by size
stale-branch-cleaner — Clean up old branches
changelog-generator — Auto-generate changelogs

Questions? Drop them in the comments or open an issue on the repo.

Stop Hardcoding Secrets: 3 Better Ways to Handle GitHub Actions Auth

Olivier Buitelaar — Fri, 20 Mar 2026 20:43:23 +0000

Stop Hardcoding Secrets: 3 Better Ways to Handle GitHub Actions Auth

You've seen it. Maybe you've even done it. A workflow YAML file with an API key pasted directly into a run: step. Or a password passed as a command-line argument that shows up in plain text in the CI logs.

Hardcoding secrets is a disaster waiting to happen. Even if your repo is private today, it might be public tomorrow. Even if it stays private, every developer with read access can now see your production credentials.

Here are the three patterns I use to handle authentication securely in GitHub Actions.

5 Real GitHub Actions Bugs Caught by Static Analysis

Olivier Buitelaar — Fri, 20 Mar 2026 19:18:06 +0000

You don't find out your CI is broken until it's too late. Here are five real GitHub Actions bugs — and how static analysis catches them before they ever run.

Static analysis for GitHub Actions workflows is still an underused idea. Most teams lint their application code, type-check their TypeScript, and run SAST on their Python. But the YAML files that orchestrate all of it? Those get copy-pasted from Stack Overflow and committed unchecked.

These are five categories of real bugs I've seen repeatedly — and how a workflow linter catches them before they cost you anything.

1. Secrets Accidentally Echoed in `run:` Steps

The bug:

- name: Deploy
  run: |
    echo "Deploying with token: ${{ secrets.DEPLOY_TOKEN }}"
    ./deploy.sh --token ${{ secrets.DEPLOY_TOKEN }}

That echo line will print your secret in plain text in the CI logs. GitHub masks known secret values in logs, but only if the secret is registered correctly — and only in most contexts. If the value gets split across lines or embedded in a longer string, masking can fail silently.

What static analysis catches:

A linter flags any ${{ secrets.* }} reference that appears inside a string passed to echo, printf, or similar commands. The fix is simple:

- name: Deploy
  env:
    DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
  run: ./deploy.sh --token "$DEPLOY_TOKEN"

Setting secrets as environment variables instead of inline expressions keeps them out of the command string entirely.

2. Unpinned Third-Party Actions (Supply Chain Risk)

The bug:

- uses: some-org/some-action@main
- uses: another-org/setup-tool@v2

Using a branch name (@main) or a mutable tag (@v2) means your workflow silently runs whatever that action points to tomorrow. A compromised update to a popular action runs with your repository's full permissions — token, secrets, and all.

This is a real supply chain risk. There have been several high-profile incidents where popular GitHub Actions were compromised via tag hijacking.

What static analysis catches:

# Flagged: mutable reference
- uses: actions/checkout@v4

# Clean: pinned to commit SHA
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

Pinning to a full commit SHA guarantees you're running exactly the code you reviewed. A linter enforces this across your entire workflow directory automatically.

3. Missing `timeout-minutes` (Runaway Jobs)

The bug:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install && npm run build

No timeout-minutes. GitHub's default timeout is 6 hours. A hung process — npm stuck on a network call, a test waiting for a port that never opens, a deploy step waiting for interactive confirmation — will silently consume your runner for 6 hours.

On GitHub-hosted runners this costs real money. On self-hosted runners it can block your entire team's CI queue.

What static analysis catches:

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 15  # required
    steps:
      - uses: actions/checkout@v4
      - run: npm install && npm run build

A linter can require timeout-minutes on every job. This single rule has saved teams significant CI bill spikes.

4. `continue-on-error: true` Silencing Real Failures

The bug:

- name: Run security scan
  continue-on-error: true
  run: ./security-scanner.sh

continue-on-error: true means a failing step is marked as "warning" but doesn't fail the job. This is occasionally legitimate — but when applied to security scans, test suites, or linting steps, failures are silently swallowed and PRs merge anyway.

Worse, it tends to spread: once one engineer adds it to unblock a stuck PR, others copy the pattern until your quality gates have no teeth.

What static analysis catches:

A linter flags continue-on-error: true on steps whose names suggest quality gates (scan, test, lint, check) — or warns on any usage and asks for a justification comment. It catches the copy-paste propagation before it becomes policy.

5. Deprecated and EOL Runtime Configurations

The bug:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-node@v3
        with:
          node-version: '16'

Node 16 has been EOL since GitHub deprecated it in their runner images. Jobs may fail with confusing errors, silently fall back to a different version, or work today but break next month when the runner image drops support.

Similar issues occur with ubuntu-18.04 runner labels (deprecated), old actions/cache versions with changed APIs, and patterns like set-output (deprecated workflow command).

What static analysis catches:

A linter maintains a list of deprecated values and flags them with suggested replacements: node-version: '16' suggests '20' or '22'; ubuntu-18.04 suggests ubuntu-latest. These are deterministic checks that never need to run a single line of your code.

Catching All of This Automatically

Running these checks manually doesn't scale, especially across a monorepo with dozens of workflow files. The solution is making them automatic and zero-friction.

workflow-guardian is a free GitHub Action that runs all of these checks statically on every PR. Add it in 30 seconds:

name: Validate Workflows
on: [pull_request]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: ollieb89/workflow-guardian@v1
        with:
          fail-on-warnings: true

It flags all five categories above as annotations directly on the changed workflow files in the PR diff — no separate dashboard, no configuration required to get started.

Static analysis for your application code is table stakes. Your CI workflows deserve the same treatment. The bugs are there — they just don't show up until something goes wrong at 2am on a Friday.

What's the worst CI workflow bug you've been bitten by? Drop it in the comments.

How to Secure Your GitHub Actions in 5 Minutes: A Step-by-Step Guide

Olivier Buitelaar — Fri, 20 Mar 2026 13:01:25 +0000

How to Secure Your GitHub Actions in 5 Minutes: A Step-by-Step Guide

You've got 100 workflows running across your org. Someone's bound to use pull_request_target without restrictions. Someone else hardcoded secrets. And nobody's checking permissions.

This article shows you exactly what to fix — right now, in under 5 minutes.

The 5-Minute Security Checklist

1. Lock Down Pull Request Workflows (2 minutes)

The biggest GitHub Actions vulnerability is using pull_request_target with untrusted code.

Bad:

on: pull_request_target

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - run: npm test

This checks out fork code and runs it with your secrets. Disaster.

Good:

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

Regular pull_request checks out your repo code, not the fork. Safe.

If you MUST use pull_request_target:

on: pull_request_target

permissions:
  contents: read
  pull-requests: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: refs/pull/${{ github.event.number }}/merge
      - run: npm test

Always set explicit minimal permissions. Never checkout the head SHA.

2. Review Your Secret Handling (2 minutes)

Secrets leak through logs, error messages, and third-party action outputs.

Bad:

- name: Deploy
  run: npm run deploy
  env:
    DATABASE_PASSWORD: ${{ secrets.DB_PASSWORD }}

This logs the password in step output if deployment fails.

Good:

- name: Deploy
  run: npm run deploy
  env:
    DATABASE_PASSWORD: ${{ secrets.DB_PASSWORD }}
  if: github.ref == 'refs/heads/main'

But better: Use GitHub's native secret masking or encrypted deploy environments.

Best:

deploy:
  environment:
    name: production
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - name: Deploy
      run: npm run deploy
      env:
        DATABASE_PASSWORD: ${{ secrets.DB_PASSWORD }}

Environments enforce branch protection and approvals.

3. Pin Action Versions (1 minute)

Never use @latest or @main. Pinning to exact commits prevents supply chain attacks.

Bad:

- uses: actions/checkout@latest
- uses: some-org/some-action@main

Good:

- uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 # v4.1.6
- uses: some-org/some-action@2c9de6ab0de0eb09362a4c5e32f39541eca7d5fa # v2.0.1

Use full commit SHA, add version tag in comment for readability.

Tools to help:

workflow-guardian — scans your workflows for unpinned actions, hardcoded secrets, unsafe permissions
actionlint (available as GitHub Action) — lints YAML syntax

The 1-Minute Audit

Run this locally to find issues:

# Install workflow-guardian
npm install -g @ollieb89/workflow-guardian

# Scan your repo
workflow-guardian scan .

This checks for:

Unpinned actions
Hardcoded secrets
Overpermissive permissions
pull_request_target without restrictions

What's Next?

For continuous enforcement, add workflow-guardian to your CI:

name: Lint Workflows

on:
  pull_request:
    paths:
      - '.github/workflows/**'

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29
      - uses: ollieb89/workflow-guardian@d4e8c9f2a1b3c5e7f9a2b4d6e8f0a1b3c5d7e9f1

Your team will never merge an unsafe workflow again.

Real Impact

One org I know had 47 workflows with unpinned actions. After pinning and setting permissions:

Zero accidental secret leaks (previously 3 per month)
Supply chain attack surface: 47x → 0
Enforcement: Manual reviews → Automatic checks

This 5-minute fix has prevented more actual incidents than I can count.

Need more? Check out the full GitHub Actions Security Toolkit — workflow-guardian, secret scanner, and more.

10 GitHub Actions Mistakes That Will Burn You (And How to Avoid Them)

Olivier Buitelaar — Fri, 20 Mar 2026 07:04:07 +0000

10 GitHub Actions Mistakes That Will Burn You (And How to Avoid Them)

I've spent the last year auditing and fixing GitHub Actions across 17+ repositories. Some mistakes are embarrassing. Some are dangerous. Most are avoidable.

Here are the ten I see over and over—and exactly how to fix them.

1. Logging Secrets (The Classic)

You're debugging a failed workflow. The obvious thing to do is echo your environment variables. So you do:

- name: Debug
  run: echo "Token is: ${{ secrets.GITHUB_TOKEN }}"

The logs are public. Everyone sees it. Congratulations, your secret is now on the internet.

The fix:

Never echo secrets in plain text
Use ::add-mask:: to mask values:

- name: Debug
  run: |
    echo "::add-mask::$(echo 'sensitive-value')"
    echo "Processing: $(echo 'sensitive-value')"

Workflow Guardian catches this by analyzing your workflow YAML for secret exposure patterns. Set it up once, sleep better.

2. Using Always-Green Credentials (No Secret Rotation)

You created a Personal Access Token (PAT) in 2023 for a GitHub Actions workflow. It's still there. It's never been rotated. It has full repo access. If compromised, the attacker has the same permissions you do.

The fix:

Use fine-grained PATs with minimal scopes
Set expiration dates (90-180 days)
Rotate before expiry
For CI/CD, prefer GitHub's built-in ${{ secrets.GITHUB_TOKEN }} (auto-scoped, auto-rotated)

3. Running Untrusted Code from pull_request Events

A user forks your repo, adds a malicious GitHub Action to their fork, opens a PR. Your workflow runs that action. They exfiltrate your secrets.

The fix: Use pull_request_target for workflows that need access to secrets, but check out the base branch. Or require approval before untrusted code runs.

4. No Timeout on Long-Running Jobs

A workflow gets stuck. No one notices. It runs for 6 hours. You burn free tier minutes for nothing.

The fix: Set timeout-minutes globally and per-job to kill stuck workflows automatically.

5. Hardcoding Environment Values (Config in Code)

You put API endpoints, database hosts, and feature flags directly in your workflow YAML. Now config is versioned, visible in diffs, and mixed with logic.

The fix: Use secrets for anything environment-specific, or repository variables for non-sensitive config.

6. No Artifact Cleanup (Storage Bloat)

You upload test results, build artifacts, and logs every run. You've never deleted them. Your storage bill is climbing.

The fix: Set explicit retention-days on artifact uploads to clean up automatically after a week or month.

7. Ignoring Exit Codes (Always Succeeding)

A step fails (exit code 1), but your workflow keeps running and marks the job as successful with || true.

The fix: Remove || true unless you really mean it. Use explicit error handling with continue-on-error: true when needed.

8. No Concurrency Control (Race Conditions in Deployments)

Two PRs merge simultaneously. Both trigger deployment workflows. Both write to production. Chaos.

The fix: Use concurrency to serialize sensitive jobs. For PR workflows, cancel previous runs on new push.

9. Large Monorepo, No Change Detection

You have 20 microservices in one repo. Every push runs tests for all services, even if you only changed one. Slow, expensive, unnecessary.

The fix: Use path filters to only run workflows for changed services. Or use tools like Nx or Turborepo to detect affected packages.

10. No Notifications on Failure (Silent Failures)

Your workflow fails. No one knows. Days pass. You merge something that depends on a broken workflow.

The fix: Notify on failure with Slack, email, or GitHub issues. Or set branch protection rules to require passing checks and enable notifications.

The Pattern

All ten of these mistakes stem from the same root cause: treating workflows like one-off scripts instead of production infrastructure.

Workflows run on every commit. They have access to your secrets. They can deploy to production. They touch customer data. Treat them accordingly.

Three things to do right now:

Audit your workflows — look for secrets in logs, overpermissioned tokens, and race conditions
Use Workflow Guardian — it catches most of these patterns automatically
Version your workflow logic — don't inline deployment scripts; reference tested, reviewed code

Toolkit Links:

Workflow Guardian — Detects security issues in your GitHub Actions YAML before production
GitHub Actions Security Toolkit — Everything to secure your workflows
PR Size Checker — Catch big PRs before they ship
Test Result Aggregator — All test results in one place

Have you hit any of these? What's your biggest workflow mistake? Hit reply.

DEV Community: Olivier Buitelaar

MCP + Workflow Patterns: Orchestrating Complex CI Pipelines

The Problem: Complexity Explosion

The Pattern: MCP-Inspired Constraints

Real Win: Catch Bugs Before They Ship

Next Steps

How OpenClaw Implements MCP for Multi-Agent Orchestration

How OpenClaw Implements MCP for Multi-Agent Orchestration

What Is MCP (and Why It Matters for Multi-Agent Systems)?

OpenClaw's MCP Architecture: Three Levels

Level 1: Plugin-Level MCP Clients

Level 2: Skill-Level MCP via mcporter

Level 3: Browser MCP Integration

Practical Walkthrough: Adding MCP Tools to Your Agents

Step 1: Install the Plugin

Step 2: Configure in openclaw.json

Step 3: Control Per-Agent Tool Access

Step 4: Use — Transparently

OpenClaw vs Generic MCP Client

How OpenClaw Compares to Google ADK and Dynatrace

Google ADK

Dynatrace

Building Your Own MCP Server for OpenClaw

Getting Started

`pull_request_target` Without Regret: Secure Fork PRs in GitHub Actions

pull_request_target Without Regret: Secure Fork PRs in GitHub Actions

Why pull_request_target is risky

The safer architecture: two workflows

Workflow A: untrusted CI (pull_request)

Workflow B: trusted repo automation (pull_request_target)

If you must run privileged follow-up after CI

Permission hardening checklist

Catch bad patterns automatically

Common “almost safe” mistakes

A practical baseline you can adopt today

Toolkit links

Stop Ghosting Your Own Repos: Automate Stale Branch Cleanup with GitHub Actions

Stop Ghosting Your Own Repos: Automate Stale Branch Cleanup with GitHub Actions

The Problem with Manual Cleanup

Automating the Audit

Step 1: Create the Cleanup Workflow

Step 2: Review the Report

Moving to Auto-Deletion

The "Safe" Auto-Delete Pattern

Protecting Important Branches

Why This Matters for DevOps

Conclusion

Part of the GitHub Actions Toolkit

I launched 3 small products to make CI debugging less chaotic

1) GitHub Actions Triage Checklist

2) CI Debugging Template

3) CI Failure Recovery Pack

Pricing

Who they're for

Why I made them

GitHub Actions Security Checklist: 12 Things to Audit Before You Ship

GitHub Actions Security Checklist: 12 Things to Audit Before You Ship

1. Pin third-party actions to a full commit SHA

2. Never use pull_request_target without extreme caution

3. Limit GITHUB_TOKEN permissions

4. Don't echo untrusted input into $GITHUB_ENV or $GITHUB_OUTPUT

5. Validate workflow syntax before merge

6. Don't store secrets in workflow files

7. Restrict who can trigger workflow_dispatch

8. Use environments for production deployments

9. Check for script injection in run steps

10. Don't use self-hosted runners for public repos

11. Rotate secrets regularly and audit access

12. Enable Dependabot for action version updates

Automate as Much as Possible

workflow-guardian vs actionlint: A Technical Deep Dive

Getting Started with workflow-guardian in 5 Minutes

Stop Hardcoding Secrets: 3 Better Ways to Handle GitHub Actions Auth

Stop Hardcoding Secrets: 3 Better Ways to Handle GitHub Actions Auth

5 Real GitHub Actions Bugs Caught by Static Analysis

1. Secrets Accidentally Echoed in run: Steps

2. Unpinned Third-Party Actions (Supply Chain Risk)

3. Missing timeout-minutes (Runaway Jobs)

4. continue-on-error: true Silencing Real Failures

5. Deprecated and EOL Runtime Configurations

`pull_request_target` Without Regret: Secure Fork PRs in GitHub Actions

Why `pull_request_target` is risky

Workflow A: untrusted CI (`pull_request`)

Workflow B: trusted repo automation (`pull_request_target`)

2. Never use `pull_request_target` without extreme caution

3. Limit `GITHUB_TOKEN` permissions

7. Restrict who can trigger `workflow_dispatch`

9. Check for script injection in `run` steps

1. Secrets Accidentally Echoed in `run:` Steps

3. Missing `timeout-minutes` (Runaway Jobs)

4. `continue-on-error: true` Silencing Real Failures