@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.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.
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.
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.
A production exception reaches RunGuard. It is grouped, classified, filtered against your safety policy, and turned into a crash packet.
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.
The opened issue triggers your Action. Claude reads the packet, investigates, and opens a pull request — all inside your GitHub, on your Anthropic key.
When the PR closes the issue or merges, GitHub webhooks update the incident in RunGuard and link the PR back to the original error.
# .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 }}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.
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.
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.
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.
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.
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.
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.
Connect a repo, set Claude Code Action as the executor, and the next incident becomes a @claude issue with full context.