Claude Code GitHub Actions for Client Work: Leave @claude in the Repo When You Leave

What Claude Code GitHub Actions Does on a Client Repo

The Claude Code GitHub Action, published as anthropics/claude-code-action, is a GitHub Action that runs Claude Code inside a repository's workflows. It has two modes and the workflow file decides which one you get. With no prompt input, it runs in interactive mode: someone mentions @claude in an issue comment, a pull request comment, a pull request review, or the body of a new issue, and Claude responds in a comment on that same thread, updating it as it works. With a prompt input, it runs in automation mode: Claude runs the prompt on whatever GitHub event triggered the workflow, with results in the workflow run log unless the prompt directs it to post.

In practice, on a client project, that turns into three things the client can see. An in-house developer or the owner types '@claude fix the TypeError in the checkout component' on an issue and gets a pull request. Every pull request gets a review, posted as inline comments on each problem found or a single summary comment when nothing is wrong. And a scheduled workflow writes a summary of yesterday's commits and open issues each morning. It is the same Claude Code the client watched you use during the build, now living inside their repository and answering to their team.

The Client-Key Handoff

The Profit Room's Client-Key Handoff is one rule: anything that keeps running in a client's repository after you leave runs on the client's identity and the client's key, never yours. The GitHub App is installed on their repo by someone with admin access on their side. The secret in the repository is an ANTHROPIC_API_KEY from a Claude Console account the client owns and pays. The workflow file is committed to their default branch. When the engagement ends, you delete your own access and the automation does not notice.

The reason is not politeness. The docs offer two ways to authenticate the action: an API key, or a CLAUDE_CODE_OAUTH_TOKEN generated from a Claude subscription with claude setup-token. The subscription token is convenient during the build because it uses your own Pro or Max plan. It is also tied to the subscription of the person who generated it, which is you. If that token sits in a client's repository after handoff, every @claude mention their team types draws down your plan, and the day you cancel or rotate it, their automation dies without warning. The docs make the same point about organization-wide installs: share an API key, not an OAuth token, because the token belongs to a person.

There is a second reason, and it is the one that protects you. The action authenticates its GitHub operations as the Claude GitHub App, so commits and comments show up under the app, not under your GitHub user. But the API key decides who pays, and a key you own inside a repo you no longer control is an open line of credit. This is the same principle as [who owns the code you build for a client](/blog/who-owns-the-code-you-build-for-a-client): the deliverable, including its running costs, ends up in the client's name. Set it up that way from the first day and [offboarding](/blog/how-to-offboard-a-claude-code-client) is a checklist instead of a scramble.

Installing It on a Client Repository

There are two setup paths and I use the manual one on client work, because it forces every piece into the client's name. The quick path, running /install-github-app from Claude Code inside the repository, does the same three steps for you, but it reuses whatever key Claude Code already has and it needs admin access to the repo, which on a client project should be their admin, not you. Both paths work only with github.com repositories; a GitLab or Bitbucket remote gets a notice and exits.

1. Have the client install the Claude GitHub App on the repository. Send them the link and the list of permissions it will ask for, because GitHub does not let anyone accept a subset. The action relies on Contents, Issues, and Pull requests, all read and write, but the app's full set is larger because Code Review and other Claude features share it. Put that in writing before they click.
2. Have the client create an API key in their own Claude Console account and add it as a repository secret named ANTHROPIC_API_KEY. You never see the key. If they do not have a Console account yet, walking them through it is part of the delivery, and it is where the conversation about [billing clients for AI API costs](/blog/bill-clients-for-ai-api-costs) naturally lands.
3. Copy the working example workflow, examples/claude.yml from the action's repository, into .github/workflows/ on a branch and open a pull request. As committed, it responds to @claude mentions using the ANTHROPIC_API_KEY secret, which is exactly the configuration you want. If the client also wants automatic reviews, add the review workflow, which invokes the code-review plugin on every opened, updated, or reopened pull request and posts findings on the PR when the prompt includes --comment.
4. Merge, then test in front of them. Open an issue, mention @claude with a small, specific request, and watch the comment update. That five minutes is the demo that makes the retainer conversation easy.

Two details worth knowing before a client asks. On a public repository, GitHub withholds secrets from runs triggered by fork pull requests, so reviews only run on pull requests from branches in the same repo. And GitHub disables a scheduled workflow on a public repository after sixty days without repository activity, so a daily-report workflow on a dormant repo stops on its own. Private client repos do not have either problem, but write it into the handoff doc anyway.

Scoping It So It Cannot Embarrass You

The action ships with two guards. On issue and pull request events, the person who triggered the run must have write access to the repository, so a random commenter on a public issue cannot spend the client's key. And on every event it rejects a bot actor unless you list the bot in allowed_bots, which stops two automations from triggering each other in a loop. Those are good defaults. They are not a scope.

Scope is the four things you set on purpose. First, --max-turns in claude_args, so a vague request cannot become a long, expensive run on the client's bill. Second, a workflow-level timeout for the same reason. Third, a CLAUDE.md in the repository root that carries the code style, the review criteria, and the parts of the system that are fragile, kept short because Claude reads it on every run; the [five-block CLAUDE.md template](/blog/claude-md-file-for-client-projects) already has the right shape. Fourth, the workflow's own permissions block, granted at the minimum the job needs. The mention workflow needs contents, pull-requests, and issues write; a review-only workflow needs only read on those plus id-token write for the app authentication. Same rule as [Claude Code permissions on a local client project](/blog/claude-code-permissions-for-client-work): grant by blast radius, not convenience.

Then the human rule, which the docs state plainly: review Claude's changes before merging. Tell the client that in the handoff, in those words. The action opens pull requests; it does not merge them, and the client's branch protection should make sure nobody can merge one without a human approval. If their CI does not run on Claude's commits, the usual cause is a github_token input set to the default GITHUB_TOKEN, which GitHub deliberately does not trigger workflows for; remove it so the action authenticates as the app. A [security review before handoff](/blog/claude-code-security-review-for-client-work) should include a read of the workflow file with these four settings checked off.

What It Costs the Client and How to Sell It

Each run consumes two things, and both belong to the client. GitHub Actions minutes, because the action runs on GitHub-hosted runners under the client's GitHub plan. And Claude API tokens, billed to the client's Console account, scaled by the length of prompts and responses, the complexity of the task, and the size of the codebase. Neither is a fixed monthly number, so do not quote one. Show them the levers instead: specific @claude requests finish in fewer turns, issue templates give Claude context up front, a concise CLAUDE.md is cheaper than a long one, and --max-turns, timeouts, and concurrency controls cap the worst case. The client sets a spend limit on their Console key and the whole thing has a ceiling.

Then sell it the way it actually helps them. During the build, the action is your safety net: every pull request you open gets a second review that knows the project, and the client sees the comments. At handoff, it becomes the leave-behind: a reviewer and a fixer that stay in their repo after you go, which is the strongest answer I have to the client who worries about being dependent on one builder. And on the [maintenance plan](/blog/package-a-maintenance-plan-for-ai-builds), it is what you tune each month: the CLAUDE.md, the review checklist, the workflow triggers, the escalations from @claude conversations that need a person. Routines cover the nightly runs on your side; the action covers what happens inside their repo on their key. Together they are the plan.