Connect GitHub and Set Guardrails for Your AI Coding Tool

Thanks to Wroxy for their help drafting these tutorials.

This guide is a companion to the outcome-based tutorials (building a website, web app, web game, or mobile game with AI). It covers two things those tutorials assume you already know: how GitHub fits into whichever AI coding tool you pick, and how to give that tool a starter set of rules so it doesn't make expensive or risky decisions on its own.

AI coding tools split into two shapes, and the cost and GitHub setup differ for each.

• Full platforms (Replit, Bolt, Lovable, v0) run in the browser, host your project themselves, and typically own the whole loop: editor, database, deploy, and often their own git hosting layer that syncs to GitHub rather than working directly against your local clone.
• CLI agents (Claude Code CLI, Cursor CLI/agent mode, OpenAI Codex CLI, Gemini CLI) run in your terminal against a real local git repository. They read and write files directly, and every change is a normal `git` commit you push yourself — there's no separate hosted sync layer to configure.

For a quick prototype you don't yet care about owning long-term, a full platform is faster to start. Once you need code review, branch protection, or CI on a real repo, a CLI agent working against your actual GitHub repo is usually the cheaper and more controllable choice — you're not paying platform markup on top of the underlying model.

Full platforms connect to GitHub through an account-level integration, not a local git config:

• Replit: Account Settings → Connected Services → GitHub, authorize the Replit GitHub App, then use "Connect to GitHub" inside a given Repl to link it to a new or existing repo. Replit pushes commits on your behalf when you use its version control panel.
• Bolt / Lovable / v0: each has a "GitHub" or "Export to GitHub" button in the project header. The first use triggers a GitHub OAuth prompt scoped to repo creation; approve it once per account, then every project gets a "Push to GitHub" action.
• In all three, only grant the integration access to the specific repositories it needs (GitHub's "Only select repositories" option during the OAuth/App install) rather than blanket access to your whole account.

CLI agents don't need a special integration — they use the same git and GitHub auth you'd use manually:

• Install the GitHub CLI (`gh`) and run `gh auth login` once, or configure a personal access token / SSH key the normal git way.
• Clone the repo (`git clone <url>`) and run the agent (`claude`, `codex`, `cursor-agent`, `gemini`) inside that directory — it now sees real git history and can commit, branch, and open PRs using your existing credentials.
• Most of these CLIs (Claude Code included) can call `gh` directly to open pull requests, meaning GitHub access is really just "is `gh` authenticated in this shell," not a separate setup step per tool.
• Keep the agent's push scope narrow: work on a feature branch, not `main`, and require a human-reviewed PR before merge — the same rule you'd apply to a new human contributor.

Before turning an agent loose on a real repo, give it a short rules file. Every major tool reads one automatically if it's named and placed correctly. Treat this as a floor, not a full policy — add project-specific rules on top.

• Claude (Claude Code): `CLAUDE.md` at the repo root. Loaded automatically at session start. Starter guardrails: state the branch to develop on and never commit directly to main/production; require tests to pass before a change is considered done; name any command that costs money (deploys, paid API calls) and require explicit confirmation before running it; list directories the agent should not modify without asking (secrets, CI config, billing code).
• OpenAI (GPT / Codex CLI): `AGENTS.md` at the repo root, plus an optional system-level preference file the CLI reads on startup. Starter guardrails: same branch and test-before-done rules as above; explicitly disallow installing new dependencies without listing them in the PR description; cap how many files a single change may touch before it must be split.
• Google (Gemini CLI): `GEMINI.md` at the repo root. Starter guardrails: require a plan/summary before multi-file edits; forbid deleting files without listing them first; require citing which files were read before claiming a bug is fixed.
• Cursor: `.cursor/rules/*.mdc` (or a single `.cursorrules` file in older setups). Starter guardrails: restrict auto-run/auto-apply mode to non-destructive commands; require manual approval for anything touching `package.json`, infra config, or environment variables; keep one rule per concern rather than one giant file.
• GitHub Copilot: `.github/copilot-instructions.md`. Starter guardrails: describe the project's coding conventions and testing commands so suggestions match house style; explicitly note any deprecated patterns Copilot should never suggest, since Copilot has no separate "ask before running" gate the way agentic CLIs do.
• DeepSeek: DeepSeek's coding tools (DeepSeek Coder via its CLI, IDE plugins, or the API) don't yet have one universal auto-loaded rules filename the way Claude Code or Gemini CLI do. The reliable approach is to pass your guardrails as the system message/prompt in whatever wrapper you're using it through (its CLI's config file, a Cursor/Continue.dev integration pointed at the DeepSeek API, or your own script) — mirror the same content as the `CLAUDE.md` starter above: branch rules, test-before-done, and a list of commands that require confirmation.

Whatever the filename, keep every guardrails file to the same core three rules to start: never push to a protected branch directly, never run a paid or destructive command without confirmation, and always run existing tests before declaring a task complete. Add tool- or project-specific rules after those three are in place, not before.