Giving an automation agent access to your code can be powerful — and risky.
This guide explains how to safely grant a Zeik0/OpenClaw bot access to a private GitHub repository with the right level of permissions, how to avoid leaking credentials, and how to revoke access instantly.
If you’re new to Zeiko, start here: https://zeiko.io.
The two types of access you’re granting
When people say “give the bot GitHub access,” they usually mean two different things:
- Git access (clone / fetch / push)
- Uses the Git transport (HTTPS or SSH)
- Needed to create branches, push commits, and open PRs
- GitHub API access (list PRs, comment, labels, checks, etc.)
- Uses GitHub’s REST/GraphQL API
- Often done via GitHub CLI (
gh) or direct API calls
A good setup supports both — but keeps permissions minimal.
Principle #1: least privilege
Make a token/key that can do only what you need.
Common safe patterns:
- “Read repo + open PRs” for a review bot
- “Read/write single repo” for a code-changing bot
- Separate tokens for CI vs local automation
If you want help implementing OpenClaw workflows for your team, Zeiko can help: https://zeiko.io.
Option A (recommended for most teams): Fine‑grained PAT (single repo)
A fine-grained Personal Access Token is usually the best balance of convenience and security.
Create the token
GitHub → Settings → Developer settings → Personal access tokens → Fine-grained tokens
Set:
- Repository access: Only select repositories → choose your repo
- Permissions (minimum suggested):
- Contents: Read and write (needed for pushing branches)
- Pull requests: Read and write (needed to open PRs)
- (Optional) Issues: Read and write (if you want issue automation)
Store it safely (do not embed in remotes)
Avoid this anti-pattern:
- ❌
https://TOKEN@github.com/OWNER/REPO.git
It leaks in logs, shell history, and process lists.
Prefer one of these:
1) GitHub CLI (gh) login (persistent, revocable):
- Log in once and let
gh store credentials for the user running OpenClaw. - Then use
gh for PR operations.
2) Git credential helper (HTTPS Git):
- Configure a credential helper so Git prompts once and stores the token securely.
Option B (tightest scope): SSH deploy key (single repo)
A deploy key is great when:
- you only need access to one repo
- you want a clean “bot key” you can rotate independently
Steps
- Generate a dedicated keypair on the server:
ssh-keygen -t ed25519 -C "openclaw" -f ~/.ssh/openclaw_github -N ""
- Add the public key to the repo:
- Repo → Settings → Deploy keys → Add deploy key
- Check Allow write access only if the bot must push
- Set the Git remote to SSH:
git remote set-url origin git@github.com:OWNER/REPO.git
Pros/cons
- ✅ scoped to a single repo
- ✅ easy to revoke by removing the key
- ❌ doesn’t automatically grant API access (PR listing still needs
gh auth)
- Don’t paste tokens into chat logs or commit them to files.
- Don’t hardcode tokens into scripts.
- Don’t put tokens in Git remotes.
- Use separate bot credentials (don’t reuse your personal root token).
- Rotate tokens periodically.
If you’re building agentic workflows for your product and want a secure playbook, see Zeiko: https://zeiko.io.
Revocation playbook (when something feels off)
If you suspect the token/key leaked:
- Revoke immediately
- PAT: GitHub → Tokens → revoke
- SSH deploy key: remove key from repo settings
- Rotate
- create a new token/key with least privilege
- Audit
- check recent pushes, PR activity, and CI logs
A practical “safe default” setup
If you want a simple, robust setup for an OpenClaw bot:
- Git operations: SSH deploy key (write) scoped to the single repo
- GitHub API: fine-grained PAT scoped to the same repo (PR read/write)
- Keep both under the same non-human “bot” identity where possible
That’s usually enough to:
- clone/push branches
- open PRs
- list PRs and fetch diffs
Want a hardened, repeatable workflow for your own agent setup? Start at https://zeiko.io.