Agents that run without you

2.1 Run Claude Code via an issue comment or label

Wire a GitHub Action so an agent responds to an @‑mention or a label instead of waiting for you to open an editor

1. Add the required secret via Settings → Secrets and variables → Actions → New repository secret
2. Install the Claude GitHub App on the repository from its marketplace page
3. Create a workflow file by copying examples/claude.yml into .github/workflows/claude.yml in your repo
4. Commit the new workflow file to the default branch using the Commit changes button
5. Post a comment containing @claude … on an issue or pull request and watch for the app’s reply
6. Apply a label (e.g., claude-fix) to an issue after configuring label_trigger in the workflow

• You'll see A comment from the “Claude” GitHub App appears on the issue or PR within roughly a minute, then edits itself in place as the agent reads the repository, makes changes, and (if it succeeds) links a new branch or pull request
• Takeaway The workflow file decides what event starts a run; the GitHub App decides what the agent is allowed to touch once it starts; you need both installations
• Check What determines whether an issue comment or label will trigger the Claude Code agent?
• Cost Free to set up. Running it spends two separate things: GitHub Actions minutes (billed by GitHub) and API tokens (billed by Anthropic, or drawn from your Claude subscription if you used an OAuth token instead of an API key). Neither is metered by "success" — a run that fails still spent both.

2.2 Verify a tool’s current repository and endpoint

Confirm the live name, organisation and API URL of an open‑source coding agent before using any tutorial that references it

1. Open your web browser and paste the legacy URL https://github.com/All-Hands-AI/OpenHands into the address bar, then press Enter
2. Observe the GitHub redirect banner that appears, confirming the repository now lives at https://github.com/OpenHands/OpenHands
3. Navigate to the new repository’s README and locate the usage snippet that still references uses: All-Hands-AI/openhands-github-action@v1 and the endpoint https://app.all-hands.dev
4. Visit the OpenHands Cloud sign‑in page at https://cloud.openhands.ai, click the Sign in button, and connect your GitHub account to a repository
5. Add the label openhands to an issue or comment @openhands on a pull request; watch OpenHands create a new pull request automatically

• You'll see A GitHub banner stating “This repository has moved” when you visit the old All‑Hands‑AI/OpenHands address
• Takeaway Always check the URL and publication date before trusting a setup guide
• Check How can you confirm that the OpenHands repository has moved to a new URL before following its setup guide?
• Cost Free — this is a five-minute verification habit, not a tool.

2.3 Limit an agent's permissions to only what it needs

Scope the token used by an unattended Claude Code Action so it can only read and write the repository elements required for its job

1. Create a personal GitHub App that requests only Contents, Issues, and Pull requests permissions
2. In your workflow file, set the github_token input to the token generated by your own app instead of the shared Claude GitHub App
3. Add a permissions: block to the job definition and list exactly the scopes needed, e.g. contents: write, issues: write, pull-requests: write (plus any required id-token or actions reads)
4. Commit the updated workflow and run it on a test branch
5. Observe the Actions log; if the job attempts an operation not listed in permissions: it fails with a 403 error

• You'll see The run aborts with an HTTP 403 in the Actions log when it tries to act outside the declared permissions block
• Takeaway Both the App or PAT supplied via github_token and the job‑level permissions: block default to broad scopes, so you must tighten each before any real execution
• Check Which part of the workflow file must list specific scopes to prevent the agent from performing unauthorized actions?
• Cost Free. Scoping a custom GitHub App or a permissions: block takes longer to set up than accepting the default (maybe twenty extra minutes once), and costs nothing to run.

2.4 Limit costs of an unattended agent

Workflow cost‑limit settings (timeout‑minutes, max‑turns, concurrency)

Set three limits that stop an unattended agent from overspending time and money on a single run

1. Edit the workflow file and add timeout-minutes to the job definition to bound wall‑clock execution
2. Add a claude_args input to the Claude Code Action step with --max-turns set to the desired limit
3. Insert a concurrency block with a group name so overlapping triggers are queued or cancelled

• You'll see The Actions run stops when the turn limit is reached and logs a message indicating the max‑turns cap was hit
• Takeaway Wall‑clock time, token usage and concurrent runs each need their own cap to prevent runaway bills
• Check What three settings can you add to a workflow to stop an unattended agent from exceeding time, token usage, or concurrent runs?
• Cost The ceilings themselves are free lines in a YAML file. What they cap is real spend: GitHub Actions minutes at GitHub's published per-minute rate, and API tokens at Anthropic's published per-token rate (or your Claude subscription's included usage, if you authenticated with an OAuth token instead of an API key).

2.5 Choose which changes can auto‑merge

Set up repository rules so only safe agent output merges automatically while other output requires human review

1. Open your repository on GitHub and navigate to Settings
2. Select Branches, then click Add rule under Branch protection rules
3. Enable Require pull request reviews before merging and Require status checks to pass in the new rule
4. Make sure the agent’s token does not have Write permission on the protected branch
5. When an agent creates a PR, open the PR and examine the Files changed tab before approving or merging

• You'll see A pull request from the Claude or OpenHands bot appears like any other PR and stays pending until a human reviews and merges it
• Takeaway The decision to auto‑merge is controlled by your branch‑protection settings, not by the agent itself
• Check Which repository configuration ensures that only reviewed pull requests created by the agent can be merged automatically?
• Cost Free — this is a policy decision and a branch-protection setting, not a paid feature.

2.6 Identify why an unattended run failed

Determine whether a failed unattended run was caused by a misunderstanding of the task or by a permission block

1. Open the repository’s Actions tab
2. Select the relevant workflow run and view its log
3. Look for an early HTTP 403 or 404 status line in the log
4. Open the issue or pull request and locate the agent’s comment thread (the conversation)
5. Compare the comment content with the log to see if it stopped abruptly or produced a result
6. Trigger a small test run that requests a disallowed permission and another that asks an ambiguous question, then observe both failure patterns

• You'll see The Actions run log shows either an early HTTP 403/404 status or a complete execution ending with a result comment
• Takeaway Early 403/404 indicates a permission issue, while a full run that produces the wrong output signals a prompt or scope problem
• Check In diagnosing a failed unattended run, what log evidence indicates a permission problem versus a task‑understanding issue?
• Cost Free to read. Reproducing a failure to practice on it costs one more run — a few cents of tokens and a minute of Actions time at most, if you keep the test task small.

2.7 Decide when not to automate a task

Choose tasks that should remain manual because the risk of unattended execution outweighs any time saved

1. Read the full task description and ask whether you can express the required outcome in one clear paragraph
2. Check if the task’s difficult part is defining correctness rather than performing a known action
3. If the answer requires judgement or design decisions, mark the task as unsuitable for an unattended agent

• You'll see No new artefact appears; you simply have confidence that the task cannot be safely specified for an autonomous run
• Takeaway Automate only well‑specified, cheap‑to‑verify work and keep a human in the loop whenever deciding what “correct” looks like is the hard part
• Check What question should you ask about a task’s outcome description to decide it is unsuitable for automation?
• Cost Free, and arguably the cheapest lesson in the chapter — the cost of skipping it shows up later, as a merged pull request nobody meant to approve.