Integration · Claude Code Action · Live

Production errors, meet @claude.

Claude Code Action already opens pull requests when someone mentions @claude in an issue. RunGuard supplies that trigger from your real production errors — with a crash packet attached — so Claude works on incidents automatically, running in your own GitHub Actions on your own key.
Live · Claude Code ActionYour Anthropic key, never oursNever auto-merges

In short

RunGuard makes Claude Code Action work from production incidents. When an error fires, RunGuard files a GitHub issue prefixed with your trigger phrase (@claude by default) and a full crash packet. Your own anthropics/claude-code-action@v1 workflow picks it up, runs Claude on your Anthropic key, and opens a pull request — RunGuard never touches your key or auto-merges.

RG-FLOWHow it worksSetup once, then automatic

From a thrown exception to a Claude pull request.

RunGuard owns everything up to the issue. Claude — on your key, in your Actions — owns the fix.
  1. 01

    Pick the executor

    In RunGuard, set Claude Code Action as the repo’s default executor. The trigger phrase defaults to @claude — change it if your workflow listens for a different one.

  2. 02

    Install the workflow

    Add the anthropics/claude-code-action@v1 workflow to your repo on issues: [opened], with your own ANTHROPIC_API_KEY in repo secrets. This is where Claude actually runs.

  3. 03

    An error fires

    A production exception reaches RunGuard. It is grouped, classified, filtered against your safety policy, and turned into a crash packet.

  4. 04

    RunGuard files the issue

    RunGuard opens a GitHub issue whose title is prefixed with your trigger phrase (@claude by default) and whose body is the crash packet — stack trace, suspected file, frequency, and scope.

  5. 05

    Your workflow runs Claude

    The opened issue triggers your Action. Claude reads the packet, investigates, and opens a pull request — all inside your GitHub, on your Anthropic key.

  6. 06

    Track to merge

    When the PR closes the issue or merges, GitHub webhooks update the incident in RunGuard and link the PR back to the original error.

RG-YAMLThe workflow you install

One Action in your repo. Your key, your runner.

This is the only thing that runs Claude. RunGuard files the issue that triggers it — and stores no Anthropic credentials.
# .github/workflows/claude.yml
name: Claude
on:
  issues:
    types: [opened]
jobs:
  claude:
    runs-on: ubuntu-latest
    steps:
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
RG-VSWhy route it through RunGuard

The Action alone needs a human. RunGuard does not.

Claude Code Action is excellent at the fix. The gap it doesn’t fill is the trigger — getting the right production incident in front of it, with context, every time.
RunGuardClaude Code Action on its own
What opens the issueA real production error, automaticallyA human types @claude on an issue by hand
Issue contextFull crash packet: stack, suspected file, frequencyWhatever the person writes in the comment
CoverageEvery grouped production incident, dedupedOnly the issues someone remembers to tag
Noise & safetyIgnore patterns + protected paths before the issue existsNo filtering before Claude starts work
Where Claude runsYour GitHub Actions, your ANTHROPIC_API_KEYYour GitHub Actions, your ANTHROPIC_API_KEY
  • RunGuard never holds an Anthropic API key — Claude runs on your key, in your Actions.
  • The trigger phrase is configurable per repo; @claude is just the default.
  • Protected paths and the never-auto-merge rule are enforced before the issue is filed.
  • Recurring errors update one issue instead of opening a new run every time.
RG-FAQQuestions

Plain answers about Claude Code Action routing.

How can Claude Code Action fix production bugs?

On its own, Claude Code Action responds when someone mentions @claude in a GitHub issue or PR. RunGuard supplies that trigger from real production errors: it files a @claude issue containing a crash packet (stack trace, suspected file, frequency) so your existing claude-code-action workflow runs Claude, investigates, and opens a pull request.

Can Claude Code access my GitHub issues?

Yes. Once the claude-code-action workflow is installed with the right repository permissions, Claude reads the issue and its crash packet, and can comment, push a branch, and open a pull request. RunGuard is what files that issue in the first place — turning a production error into the issue Claude works from.

Does RunGuard need my Anthropic API key?

No. RunGuard never holds an Anthropic key. Claude runs entirely inside your own GitHub Actions workflow using the ANTHROPIC_API_KEY stored in your repo secrets. RunGuard only files the issue that triggers it.

How is this different from using Claude Code Action directly?

Claude Code Action waits for a human to tag @claude on an issue. RunGuard turns production errors into those issues automatically — grouped, deduplicated, filtered through your safety policy, and pre-loaded with a crash packet — so incidents get worked on without anyone watching the error dashboard.

What do I need to install in my repo?

A GitHub Actions workflow using anthropics/claude-code-action@v1 triggered on issues: [opened], plus an ANTHROPIC_API_KEY secret. RunGuard files issues through its GitHub App installation; your workflow does the rest.

Can I change the @claude trigger phrase?

Yes. The trigger phrase is a per-repo setting in RunGuard and defaults to @claude. Set it to whatever your workflow listens for so the issue RunGuard files matches your Action’s trigger.

Will RunGuard auto-merge the fix?

Never. Auto-merge is never enabled. Claude’s change always arrives as a pull request for your review, and protected paths are enforced as a hard gate.

Point your production errors at Claude.

Connect a repo, set Claude Code Action as the executor, and the next incident becomes a @claude issue with full context.