Teaching Agents to Ship: GitHub Auth in NanoClaw Containers

By Peyton Spencer

AI coding agents are great at writing code. But getting that code from “here’s my change” to “PR is live” usually requires human intervention. The agent makes the changes, you switch to your terminal, push the branch, open GitHub, fill out the PR form… it breaks the flow.

We fixed that in our NanoClaw fork.

What is NanoClaw?

NanoClaw by Gavriel Cohen is a WhatsApp interface for Claude Code. It runs Claude agents in sandboxed Docker containers, giving each conversation its own isolated environment. The security model is thoughtful: containers get minimal permissions, SSH keys are blocked via mount-security, and file access is tightly controlled.

It’s a solid foundation for autonomous AI agents. But there was a gap: agents couldn’t ship their own work.

The Problem

When an agent finished coding, it would commit locally and… stop. To actually create a PR, you’d need to:

  1. Note the branch name
  2. Switch to your terminal
  3. Navigate to the repo
  4. Push the branch
  5. Open GitHub
  6. Fill out the PR form

Not a huge deal for one PR. But when you’re iterating quickly with an agent — “try this approach, actually change that, now add a test” — the context switching adds up. The agent knows what it built and why. It should be able to open the PR.

The Solution

We forked NanoClaw and added GitHub authentication for container agents. Now agents can:

  • Push branches to GitHub
  • Create pull requests with descriptions
  • Update existing PRs
  • Check CI status

All from inside the sandboxed container.

How It Works

The implementation has three parts:

1. Install gh CLI in the Container

We added the GitHub CLI to the Docker image. It’s a single binary with no complex dependencies, and it handles auth, git credentials, and the GitHub API in one tool.

# Install gh CLI
RUN curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | \
    dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg && \
    chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg && \
    echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | \
    tee /etc/apt/sources.list.d/github-cli.list > /dev/null && \
    apt update && \
    apt install gh -y

2. Pass GitHub PAT Through Environment Variables

NanoClaw already had a system for passing environment variables to containers. We piggyback on that:

// Container gets GITHUB_TOKEN from user's config
GITHUB_TOKEN=ghp_yourPersonalAccessToken

Users generate a classic GitHub PAT with repo and workflow scopes, add it to their NanoClaw config, and it’s automatically available in agent containers.

3. Auto-Configure Git Credentials in Entrypoint

The container entrypoint checks for GITHUB_TOKEN and configures everything automatically:

if [ -n "$GITHUB_TOKEN" ]; then
  # Authenticate gh CLI
  echo "$GITHUB_TOKEN" | gh auth login --with-token

  # Configure git to use gh for credentials
  git config --global credential.helper '!gh auth git-credential'

  # Set git to use HTTPS (not SSH)
  git config --global url."https://github.com/".insteadOf git@github.com:
fi

Now when an agent runs git push or gh pr create, it just works.

Why HTTPS + PAT?

NanoClaw intentionally blocks SSH keys via mount-security. This is good: you don’t want agents accessing your SSH keys, which might have access to other systems.

We could have weakened this by mounting SSH keys anyway. But that’s the wrong trade-off.

Instead, we use HTTPS authentication with a scoped PAT. The token:

  • Only has GitHub permissions (repo, workflow)
  • Can be revoked instantly
  • Can be scoped to specific repos if needed
  • Doesn’t grant access to SSH-protected systems

This maintains the security-first philosophy of NanoClaw while giving agents the capabilities they need.

What This Enables

With GitHub auth, agents can complete full development workflows:

Before:

Agent: I've fixed the bug and committed the changes on branch fix/auth-error
You: [manually push branch, open GitHub, create PR]

After:

Agent: I've fixed the bug. Creating PR...
       Done: https://github.com/yourorg/yourrepo/pull/42

The agent owns the full loop. It can:

  • Iterate on feedback (“I updated the PR with better error messages”)
  • Check CI results (“Tests are passing”)
  • Respond to review comments (“I addressed your concerns in commit abc123”)

This is especially powerful for autonomous workflows like scheduled tasks or webhook-triggered agents. An agent can detect an issue, fix it, open a PR, and notify you — all without human intervention until review time.

Real-World Example

This blog post? Written by an agent that also created the PR.

I asked Claude (running in a NanoClaw container) to add solid-grab to the Omni Aura landing page and write a blog post about it. Claude:

  1. Explored the codebase
  2. Deleted placeholder blog posts
  3. Wrote a new blog post
  4. Updated the homepage
  5. Created a feature branch
  6. Committed with a proper message
  7. Pushed to GitHub
  8. Opened PR #6

All autonomously. I reviewed and merged. Total human interaction: one initial message, one merge click.

That’s the workflow we want: agents handle implementation, humans handle decisions.

Get It

Our fork is at github.com/omniaura/nanoclaw.

Setup is straightforward:

  1. Generate a GitHub classic PAT with repo + workflow scopes
  2. Add GITHUB_TOKEN=your_pat_here to your NanoClaw .env
  3. Restart containers

Agents will automatically have GitHub access. No mount configs, no SSH key management, no manual credential setup.

Why This Matters

AI agents are crossing the threshold from “helpful assistants” to “autonomous workers.” The bottleneck isn’t their coding ability anymore — it’s their ability to operate independently.

Shipping code requires pushing branches, opening PRs, updating descriptions, responding to CI failures. These are simple operations, but they’ve been human-only because of authentication barriers.

By solving auth in a secure, scoped way, we remove that barrier. Agents can own entire workflows. They can work overnight. They can respond to incidents. They can iterate on PRs without waiting for you to push each commit.

This is what autonomous AI workflows look like: agents that can finish what they start.

Fork: omniaura/nanoclaw Original: gavrielc/nanoclaw