Giving your OpenClaw agent access to a GitHub repo, the safe way
The agent generates a keypair, you add the public half as a single-repo deploy key, and no token ever touches the chat. Plus when you need a fine-grained PAT instead.
The safe pattern has three steps: your agent generates an SSH keypair on its own machine, you add the public half as a deploy key on the one repository it needs, and no credential ever passes through the chat. A deploy key is scoped to a single repo and read-only by default, which makes it the right-sized credential for an agent. (Looking for OpenClaw’s own GitHub? That’s github.com/openclaw/openclaw.)
First rule: never paste a token into the chat
Everything you tell an OpenClaw agent is written down: chat transcripts, session logs, sometimes memory files. OpenClaw’s own security guidance says to keep secrets out of the agent’s prompts and reachable filesystem, and a GitHub token pasted into a conversation violates both at once. The deploy-key pattern below exists precisely so that the only thing that ever crosses the chat is a public key, a string that is harmless by design.
The deploy-key pattern, step by step
The pattern takes about three minutes:
- 1. Ask the agent to make a key. Tell it: “Generate an SSH keypair for GitHub access and show me the public key.” OpenClaw’s
exectool runs shell commands, so it will runssh-keygenitself: the private key is born on the agent’s machine and never needs to leave it. - 2. Add the public key as a deploy key. In the repository (not your account settings): Settings → Deploy keys → Add deploy key, paste the public key, give it a name you’ll recognize in an audit six months from now (“openclaw-pod”).
- 3. Decide about write access deliberately. Deploy keys are read-only unless you tick the box. GitHub’s docs are blunt about the upgrade: a deploy key with write access can do what a repo admin can. Grant it only if the agent’s actual job is pushing commits.
Then have the agent clone with the SSH URL ( git@github.com:you/repo.git ) and you’re done. The blast radius if the agent’s machine is ever compromised: exactly one repository, at exactly the access level you chose. GitHub enforces the scoping for you: a key attached to one repo as a deploy key cannot be reused on another.
What a deploy key can’t do
Deploy keys speak git: clone, pull, push. They don’t authenticate the GitHub API, so if you want the agent working with issues, pull requests, or CI logs (OpenClaw ships a bundled github skill built on the gh CLI for exactly this), it needs a token after all. The right one is a fine-grained personal access token: GitHub lets you restrict it to selected repositories with minimal permissions, and unlike a deploy key it supports an expiry date. Create it yourself and place it on the agent’s machine directly (via gh auth login in the agent’s shell, or an env var in its service config): placing, again, not pasting into chat. If one machine needs many repos, GitHub’s own suggested shape is a machine user: a separate account holding just the automation’s access.
The repo your agent already has
One more thing worth knowing: your agent’s workspace (its memory, identity, and notes) is already a git repository; OpenClaw initializes it automatically when git is installed. The docs recommend pushing it to a private GitHub repo as a backup, and the same deploy-key pattern covers that too. Two cautions carry over: keep the repo private (it’s your agent’s memory, and backups of agent state deserve the same care as the state), and keep actual secrets out of the workspace: the docs are explicit that even a private repo is no place for API keys.