OpenClaw GitHub: How to Deploy From Your Own Repo

OpenClaw's connection to GitHub is where it stops being a chat tool and starts being an engineering operator. Your agent can clone repos, create branches, commit code, push changes, trigger deploys, review PRs, and run coding subagents against your actual codebase — all without you touching the keyboard.

This guide covers the full setup: authenticating OpenClaw with GitHub, configuring auto-deploy workflows, using Codex and Claude Code agents on your repos, and managing branches from sessions.

Prerequisites

Before connecting GitHub:

• OpenClaw installed and running (openclaw gateway status returns active)
• A GitHub account with at least one repo
• GitHub Personal Access Token (PAT) with repo scope
• The coding-agent skill installed (clawhub install coding-agent)

Authenticating with GitHub

OpenClaw accesses GitHub via standard git credentials. The recommended approach is a Personal Access Token stored in your workspace's TOOLS.md or environment.

Generate a PAT

In GitHub: Settings → Developer Settings → Personal Access Tokens → Tokens (classic)

Required scopes:

• repo (full repo access)
• workflow (if you want to trigger GitHub Actions)
• read:org (optional, for org repos)

Set expiration based on your risk tolerance. For an always-on agent, 90-day tokens with a reminder to rotate work well.

Configure Git Credentials

The cleanest method — configure git credential storage so OpenClaw's shell sessions authenticate automatically:

git config --global credential.helper store
echo "https://<your-username>:<your-token>@github.com" >> ~/.git-credentials

Then tell your agent where to find your GitHub username and confirm the token is configured:

In your workspace TOOLS.md, add:

## GitHub
- Username: your-github-username
- Repo: your-org/your-repo (private)
- Token: configured in ~/.git-credentials
- Default branch: main

Your agent reads TOOLS.md at session start. From that point, any GitHub operation just works.

SSH Alternative

If you prefer SSH keys over PAT:

ssh-keygen -t ed25519 -C "openclaw@yourdomain.com" -f ~/.ssh/openclaw_github
cat ~/.ssh/openclaw_github.pub
# Add the public key to GitHub → Settings → SSH Keys

Add to ~/.ssh/config:

Host github.com
  IdentityFile ~/.ssh/openclaw_github
  User git

Test it:

ssh -T git@github.com

Working With Repos From Sessions

Once auth is configured, your agent can interact with GitHub through natural language or explicit commands. The agent runs git commands via the exec tool internally.

Common operations your agent handles:

You: Clone my repo to /root/my-project
Agent: [runs git clone, confirms success]

You: What branch is currently checked out in /root/my-project?
Agent: [runs git status, reports branch name and any uncommitted changes]

You: Create a branch called feature/new-landing-page and push it
Agent: [git checkout -b feature/new-landing-page && git push -u origin feature/new-landing-page]

You: Commit all current changes with message "Add pricing section"
Agent: [git add -A && git commit -m "Add pricing section" && git push]

The agent treats your repo like any other part of the workspace — it reads files, makes changes, and commits them. The key is giving it clear instructions about your branching conventions (document these in AGENTS.md so it knows your workflow without asking every time).

Auto-Deploy Setup

The most useful pattern: push to a branch → deploy automatically. OpenClaw doesn't replace your CI/CD pipeline — it integrates with it.

GitHub Actions Integration

Create a workflow that triggers on push to your deployment branch. Here's a minimal example for an Astro site deploying to a VPS:

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [master, main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Deploy to VPS
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.VPS_SSH_KEY }}
          script: |
            cd /root/myproject
            git pull origin master
            npm run build
            systemctl restart myapp

Add your VPS credentials as GitHub Secrets. Now when your OpenClaw agent commits and pushes, the deploy fires automatically.

Your agent can also check deploy status:

You: Did the last deploy succeed?
Agent: [checks GitHub Actions API via web fetch, returns last workflow run status]

Webhook-Based Deploys

For more control, set up a webhook on your server that GitHub pings on push:

# Simple deploy webhook with Python
cat > /root/deploy-webhook.py << 'EOF'
from http.server import HTTPServer, BaseHTTPRequestHandler
import subprocess, json, hmac, hashlib, os

SECRET = os.environ.get('WEBHOOK_SECRET', '').encode()

class Handler(BaseHTTPRequestHandler):
    def do_POST(self):
        length = int(self.headers['Content-Length'])
        body = self.rfile.read(length)
        
        sig = self.headers.get('X-Hub-Signature-256', '')
        expected = 'sha256=' + hmac.new(SECRET, body, hashlib.sha256).hexdigest()
        
        if hmac.compare_digest(sig, expected):
            subprocess.Popen(['/root/deploy.sh'])
            self.send_response(200)
        else:
            self.send_response(403)
        self.end_headers()

HTTPServer(('0.0.0.0', 9000), Handler).serve_forever()
EOF

Register the webhook in GitHub repo settings pointing to https://yourdomain.com:9000. Your agent can trigger deploys by pushing; the server handles the rest.

Using Codex and Claude Code Agents on Your Repo

This is where OpenClaw's GitHub integration gets powerful. The coding-agent skill lets your main agent delegate actual coding work to specialized subagents that run against your repo.

Claude Code on Your Codebase

Claude Code is ideal for complex, multi-file refactors, feature development, and code review. It runs as a subprocess with --print --permission-mode bypassPermissions:

You: Refactor the authentication module in /root/myapp to use JWT instead of sessions. 
     Keep backward compatibility. Save changes to the current branch.

Your main agent, using the coding-agent skill, translates this into:

cd /root/myapp && claude --print --permission-mode bypassPermissions \
  "Refactor the authentication module to use JWT instead of sessions. 
   Keep backward compat. Modify only files in src/auth/. 
   Commit when done with message 'Refactor: JWT auth'"

The coding agent reads the codebase, makes changes, and commits. Your main agent monitors and reports back.

Codex for Iterative Development

Codex (OpenAI's coding model) runs with PTY enabled for interactive sessions:

You: Spawn Codex to build a rate limiting middleware for the Express API in /root/api

The coding-agent skill handles the PTY session management, passes your working directory and instructions, and waits for completion.

Practical Workflow

For a real feature build, the pattern looks like:

1. You describe what you want in natural language
2. Main agent creates a feature branch: git checkout -b feature/rate-limiting
3. Main agent spawns a coding subagent with the branch checked out
4. Coding subagent builds, tests, and commits
5. Main agent pushes the branch
6. Main agent can optionally open a PR via GitHub API
7. You review the PR; merge triggers autodeploy

This entire flow runs without you writing a single line of code or touching the terminal.

Branch Management From Sessions

Your agent can manage your entire branching workflow:

List branches:

You: What branches exist in the repo?

Create and switch:

You: Create a hotfix branch off main for the broken login page

Merge (locally):

You: Merge the feature/pricing branch into main and push

Check PR status:

You: Are there any open PRs in the repo?
Agent: [fetches via GitHub API, lists open PRs with titles and authors]

Delete merged branches:

You: Clean up all merged branches in /root/my-project
Agent: [runs git branch --merged | grep -v main | xargs git branch -d, then git push --prune]

Document your branching conventions in AGENTS.md so the agent never guesses:

## Git Rules
- Feature work: branch off master, prefix feature/
- Hotfixes: branch off master, prefix hotfix/
- Never commit directly to master without a PR (except solo projects)
- Always run build before pushing: npm run build

Workspace Git Rule

One important constraint: never clone repos inside your OpenClaw workspace directory (~/.openclaw/workspace). Nested .git folders break git add -A on the workspace itself.

Clone repos outside the workspace:

# Good
git clone https://github.com/yourorg/yourrepo /root/yourrepo

# Bad — breaks workspace git
git clone https://github.com/yourorg/yourrepo ~/.openclaw/workspace/yourrepo

If you need to reference repo files from workspace, symlink them or reference by absolute path.

Connecting to Private Repos and Orgs

For org repos, make sure your PAT has read:org scope and that SSO is authorized if your org uses SAML SSO:

GitHub → Your org → Personal access tokens → Authorize for SSO

For GitHub Apps (more secure than PATs for production setups), the setup is more involved but gives you fine-grained permission control per repo. Document the App credentials in your TOOLS.md once configured.

---

For running coding agents without GitHub (local-only builds), see the OpenClaw Skills guide. For managing your whole deployment from the web UI, see OpenClaw Dashboard.

Want an agent that commits code while you sleep? Start with strong repo permissions, branch rules, and deployment checks.