PR-only Agents with OpenClaw (SetupClaw): A Safe Git Workflow for AI Changes on a Hetzner VPS

If you can message OpenClaw from Telegram and it’s configured with repo / automation tools, it can become a remote control plane for code and infrastructure. That’s useful—and it’s also why SetupClaw’s Basic Setup (£249) leans on a simple, enforceable guardrail for repo changes: PR-only.

What “PR-only” means (precisely)

“PR-only” is not a vibe; it’s a workflow boundary:

• The agent may edit files, run tests/linters, and commit locally.
• The agent may push a feature branch.
• The agent may open a pull request.
• The agent must not push directly to protected branches (e.g., main).
• The agent must not deploy directly as part of the same request.

PR-only reduces the risk of silent changes, but you still need: protected branches, scoped tokens, and CI checks.

Why GitHub PRs are the approval UI (and why that’s good)

GitHub pull requests already provide the things you’d want from an “AI approval surface”:

• A diff view (what changed)
• Review comments
• Required approvals
• Required checks (CI)
• An audit trail

SetupClaw uses this instead of inventing a new approval UI.

Enforce PR-only at the repository layer (branch protection)

The critical step is making PR-only non-negotiable by configuring branch protection in GitHub.

Recommended baseline for main:

• Require a pull request before merging
• Require at least 1 approval
• Require status checks to pass (choose a small, reliable set: lint + unit tests)
• Disable force pushes

This is the difference between “the agent should do PR-only” and “the repo refuses anything else.”

End-to-end workflow on a VPS (what actually happens)

A practical PR-only loop looks like this:

1. Telegram request arrives (from an allowlisted user / approved chat).
2. OpenClaw runs the repo agent in a working directory.
3. The agent:
   • creates a new branch
   • applies edits
   • runs checks (lint/tests)
   • commits
4. The agent pushes the branch and opens a PR.
5. The agent posts the PR link back to Telegram (usually in a private DM by default).
6. You review + merge in GitHub.

A VPS is convenient because it’s always on, but PR-only works anywhere the agent can access the repo and run checks.

Minimal starter scripts (small, deterministic, reviewable)

SetupClaw often leaves a tiny set of scripts so the workflow stays consistent. You don’t need a huge framework; you need repeatability.

Here’s a compact example that creates a timestamped branch:

#!/usr/bin/env bash
set -euo pipefail

git rev-parse --show-toplevel >/dev/null
branch="ai/$(date -u +%Y%m%d-%H%M%S)"

git switch -c "$branch"
echo "$branch"

Pair that with:

• scripts/ai-check.sh → runs lint/tests
• scripts/ai-pr.sh → runs gh pr create with a filled title/body

The point is: the bot’s behaviour is observable. If something goes sideways, you can reproduce the steps manually.

Using gh pr create for auditable PR creation

The GitHub CLI is a pragmatic building block:

• It keeps PR creation scripted.
• It outputs the PR URL (easy to paste back to Telegram).
• It works cleanly on a headless VPS.

In a Basic Setup, the agent typically needs permissions to:

• push branches
• open PRs

…but not to bypass branch protection. This reduces blast radius if credentials leak.

How PR-only pairs with cron and “reliable automation”

Cron makes the work run on time (dependency bumps, formatting, routine checks). PR-only makes the output safe:

• Scheduled job opens a PR every week.
• CI runs.
• You merge when you’re ready.

Result: automation produces proposals, not silent deployments.

Common objections (and the honest answers)

• “PR-only is too slow.” It’s usually the smallest guardrail that preserves speed: you still request changes in Telegram, but the merge stays intentional.
• “This sounds like enterprise bureaucracy.” It’s one branch + one PR + one review. You get rollback and an audit trail without building a custom platform.
• “Won’t the bot need broad GitHub permissions?” Not if you scope it properly. Branch protection remains the hard backstop.
• “PR-only doesn’t stop bad PRs.” Correct. It stops silent bad changes. Human review + CI checks remain the safety net.

What SetupClaw hands off (so you can keep operating safely)

A good Basic Setup handoff includes:

• A short PR-only runbook (naming, review steps, rollback)
• Repo settings checklist (protected branches + required checks + required reviews)
• Where credentials live on the VPS and how to rotate them
• A note on where PR links will be posted (DM vs group) aligned with Telegram allowlists/require-mention rules

CTA

If you want OpenClaw on a Hetzner VPS set up so it can propose repo changes safely from Telegram—but never merge silently—SetupClaw Basic Setup is £249. Email alex@clawsetup.co.uk and share which repo(s) you want to put behind a PR-only workflow.