Your Website on GitHub, Run by AI

What you'll end up with

You ask Claude or ChatGPT for a change in plain English, and a few minutes later it's live on your site. Setup takes about an hour, once; after that you don't touch code unless you want to.

Both routes end on main. The safe route adds a pull request you approve first; GitHub Pages then publishes whatever is on main.

At a glance

You do the clicks in settings; the AI does everything inside the repo. In this setup the AI can't touch GitHub settings, DNS or Cloudflare, so those steps are always yours.

Before you start

You need one free account, one paid AI plan (two if you want both Claude and ChatGPT), and about an hour the first time.

You only need one AI plan. Pick whichever you already pay for.

Six words you'll see a lot

One thing to know up front: on a free GitHub account, Pages only works on public repos. Anyone can read your site's files, so never put passwords, keys or private data in them.

Step 1: Create the repo and switch on Pages

Six steps and one file; your site goes live at https://YOURNAME.github.io.

1. Sign up at github.com. Pick your username with care: it becomes part of your web address.
2. Click + (top right), then New repository.
3. Name it exactly YOURNAME.github.io, using your username. Choose Public, tick Add a README file, then click Create repository.
4. Click Add file, then Create new file. Name it index.html, paste the starter page below, and click Commit changes.
5. Open Settings, then Pages. Under Build and deployment, set Source to Deploy from a branch, Branch to main, folder / (root). Click Save.
6. Wait a minute or two, then open https://YOURNAME.github.io.

Starter page:

<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>My site</title>
</head>
<body>
  <h1>It works</h1>
</body>
</html>

One repo can hold dozens of mini-sites. Put each in its own folder (piano/index.html) and it appears at YOURNAME.github.io/piano.

Check it worked: Settings, Pages says your site is live, and the address shows "It works".

Step 2 (optional): Use your own domain

Skip this if YOURNAME.github.io is fine. Order matters: tell GitHub about the domain first, then change DNS. GitHub warns that doing it the other way round can let someone else host a site on your domain.

1. Buy a domain from any registrar, such as Namecheap, 123-reg or Cloudflare.
2. Recommended: verify the domain with GitHub, which stops anyone else claiming it. Click your profile picture, then Settings, then Pages (under Code, planning, and automation), then Add a domain. GitHub shows a TXT record; add it at your registrar, come back and click Verify. Keep that record for good. (GitHub's steps)
3. In your repo, open Settings, then Pages. Type your domain under Custom domain and click Save. GitHub adds a file called CNAME to your repo; leave it there.
4. At your registrar, open the DNS settings (sometimes called DNS management or Advanced DNS). Screenshot every record first, so you can put things back. Then delete only the records that send your website somewhere else, for @ and www: A, AAAA, CNAME, ALIAS, and any URL redirect or forwarding record. They usually point at a parking page. Leave MX and TXT records alone: they run your email and the verification above. Then add these five:

5. Wait. DNS changes can take up to 24 hours to spread.
6. Back in your repo's Settings, Pages, tick Enforce HTTPS. The box can take up to 24 hours to appear.

Check it worked: Settings, Pages shows the DNS check passing, and your domain opens with a padlock. Stuck? If your domain already has CAA records, one of them must allow letsencrypt.org, the company GitHub uses for certificates.

Two safety rules: never add a wildcard record (*.yourname.co.uk), and if you ever turn the site off, delete these DNS records the same day. Each repo takes one domain, so a second domain needs a second repo.

Step 2b (optional): Put Cloudflare in front

Cloudflare's free plan runs your domain's DNS and can sit between visitors and GitHub. That unlocks a few things GitHub Pages can't do on its own. Skip this until you want one of them.

"Orange cloud" means Proxied: traffic flows through Cloudflare. "Grey cloud" means DNS only: Cloudflare just points visitors at GitHub.

1. Create a free account at cloudflare.com, add your domain, and pick the Free plan. Bought the domain from Cloudflare? It already runs your DNS, so skip to step 5.
2. Cloudflare copies your existing DNS records. Compare its list with your registrar's current list, and add anything missing. Then check your screenshot from Step 2: every MX and TXT record on it must be in Cloudflare, or your email stops when you switch.
3. At your registrar, turn DNSSEC off if it's on. Left on, it can take your site and email offline during the switch. You can turn it back on later, from Cloudflare.
4. Still at your registrar, swap the nameservers for the two Cloudflare gives you. Wait until Cloudflare shows the domain as Active (up to 24 hours).
5. Set every website record to DNS only (grey); Cloudflare often brings them in as Proxied. Check GitHub's Settings, Pages still shows your domain working with Enforce HTTPS ticked.
6. Only if you want the orange-cloud features: switch the website records (the four A records and the www CNAME) to Proxied, then open SSL/TLS and set the encryption mode to Full (strict).
7. Email Routing, only if nothing receives email at this domain yet: open Email Routing, add your new address and your real inbox, and click the link in the verification email. Cloudflare asks to delete any old MX records and won't switch on until you do. Already using Google Workspace, Microsoft 365 or a mailbox from your registrar here? Skip this step, because it would cut that inbox off. Add new addresses in that provider instead.

Check it worked: the site loads with a padlock on your domain. If you set up Email Routing, a test email to the new address lands in your inbox.

Three traps:

• Never pick Flexible encryption. GitHub sends every visitor to HTTPS, and Flexible talks to GitHub over plain HTTP, so the two bounce forever ("too many redirects").
• Certificate renewals. GitHub renews its HTTPS certificate by checking your DNS. People report renewals failing while the orange cloud is on; GitHub doesn't document this. If GitHub flags a certificate problem, go grey for a day, let it renew, then switch back.
• Nothing here makes a page private. A GitHub Pages site is public, and on a free account so is its source code. Never put anything confidential on it.

Want the source code kept private, or a preview link for every AI change before you merge? Cloudflare can host the site itself from a private repo, and it posts a preview link on every pull request. That's a bigger move away from GitHub Pages, so treat it as a later upgrade.

Step 3: Connect Claude

Claude edits your site through Claude Code in the cloud, which you reach at claude.ai/code or the Code tab in the Claude phone app. It needs a Pro, Max or Team plan, or an Enterprise seat that includes Claude Code. On Team and Enterprise plans, an Owner must switch on the GitHub connector first.

1. Go to claude.ai/code and sign in.
2. When it asks, click to connect GitHub, then approve on GitHub's page. You're sent back automatically.
3. Optional: install the Claude GitHub App on your account. A public repo works without it, but it's needed for private repos and lets Claude watch a pull request and fix failed checks.
4. On Pro and Max, Claude makes an environment called Default for you. On Team and Enterprise you'll see a short form instead: leave it as it is and click Create & finish.
5. Pick your repo in the selector under the message box. Set the mode to Accept edits (Claude changes and pushes without stopping) or Plan (it shows you the plan first).
6. Type what you want. Claude does the work and ships it the way your rules say: straight to main, or on a branch. Until the AI manual's first run sets those rules, it pushes a branch; open the diff, click Create PR, then merge it on GitHub.

Check it worked: your repo appears in the selector at claude.ai/code.

Claude can also push straight to main if you tell it to; nothing on Claude's side blocks that. If you'd rather it couldn't, add a branch protection rule on GitHub (see House rules).

Make it remember your rules. At the start of every session Claude reads your repo's CLAUDE.md, or AGENTS.md if there's no CLAUDE.md. Put your house rules there once and you never repeat them; the AI manual's first run writes the file for you.

To disconnect later, remove GitHub at claude.ai/customize/connectors.

Step 4: Connect ChatGPT (Codex)

ChatGPT edits your site through Codex cloud. OpenAI lists cloud tasks on Plus, Pro, Business, Edu and Enterprise; its pricing page doesn't confirm them for Free or Go.

1. Open ChatGPT on the web or the desktop app and sign in.
2. Choose Work in, then Cloud, and open Select environment.
3. Choose Create environment. Already made one for this repo? Select it and skip to step 6.
4. Pick your site's GitHub repo and select Get started. Connect GitHub if it asks, and give it access to that repo.
5. Codex checks the repo and tests the setup. Review it, save, and click Publish; wait for "Environment published". Do steps 2 to 5 on web or desktop, since the phone app can only pick an existing environment.
6. Select Start a new task, describe the change, and send it.
7. When it's finished, commit or open a pull request, then merge it on GitHub.

Check it worked: you see "Environment published", and your repo is listed when you start a task.

Codex usually works on a branch named codex/… and opens a pull request for you to merge. OpenAI's docs don't say whether it can push straight to main, so treat a pull request as its normal route.

Make it remember your rules. Codex reads a file called AGENTS.md in your repo, the same way Claude reads CLAUDE.md. House rules below shows how to keep one set of rules for both.

Step 5: Ask for changes

A good request names the file, the change, and how to ship it. Vague asks get vague edits.

After you hit send:

1. The AI copies your repo, edits the files and commits them.
2. It pushes to main, or to a branch with a pull request for you to merge.
3. Once the change is on main, GitHub Pages republishes. Usually that takes a minute or two.
4. To check, open your repo's Actions tab: a green tick on "pages build and deployment" means it's live.
5. Still seeing the old page? Your browser kept a copy. Press Ctrl+Shift+R (Cmd+Shift+R on a Mac) to reload it fresh.

Undo a bad change

Nothing is ever lost; every change sits in the repo's history. Undoing means adding a new change that reverses the bad one.

Never ask an AI to "force push" or "reset main". Both rewrite history, and they can wipe out work that's already live.

House rules

Four rules stop most problems before they start.

1. Pick one route per repo. Straight to main suits a small personal site (fast, and mistakes go live). Pull requests suit anything other people rely on (one extra click, and you see every change first).
2. One AI at a time per repo. If Claude and Codex both have open branches touching the same file, the second one to merge hits a conflict. Merge one before starting the other.
3. Nothing secret in a public repo. No passwords, API keys or personal data. Deleting a file later doesn't help; the history keeps it.
4. One rulebook for both AIs. Put your rules in AGENTS.md at the top of the repo. Codex reads it, and Claude Code reads it too when there's no CLAUDE.md. If you do keep a CLAUDE.md, make its first line @AGENTS.md so Claude pulls the same rules in.

Want pull requests enforced rather than just requested? In GitHub, open Settings, then Branches, and add a rule for main with Require a pull request before merging ticked. If Require approvals is ticked underneath it, untick it: GitHub won't let you approve your own pull requests, and the AI's pull requests count as yours. Then tick Do not allow bypassing the above settings, or your own account (and any AI working as you) can still push straight in.

The AI manual's first run writes a fuller AGENTS.md for you. To write your own instead, start here:

# Site rules

- This is a static GitHub Pages site. No build step, no frameworks.
- Each project is one self-contained index.html in its own top-level folder.
- Link every new project from the home page (/index.html).
- Never commit passwords, API keys or other people's personal data. The repo is public.
- Keep the CNAME and .nojekyll files. Only change CNAME if I ask to change the domain.
- Ship changes by: [pushing straight to main | opening a pull request].
- If another agent has an open branch touching the same files, stop and ask me first.
- Stop and ask before anything that could affect the domain, DNS or email.
- After shipping, reply with the live link to check.

Troubleshooting

Most problems match one of these rows.

Hand it to an AI

The AI manual below holds everything in this guide, written as rules an AI can follow. Copy it (or download the file) into Claude or ChatGPT, fill in section 0, and set the MODE line.

After the first run, a request as short as "add a dark mode toggle to the piano page" is enough.

AI manual

This is the guide rewritten as rules for an AI. Paste it into Claude or ChatGPT, fill in section 0, and set the MODE line. Its step numbers match the guide above.

# GitHub Pages site manual (for AI assistants)
Version 1.0, 2026-10-23. For Claude (Claude Code) and ChatGPT (Codex).
Independent guide; not affiliated with GitHub, Anthropic, OpenAI or Cloudflare. Licence: CC BY 4.0.
Follow this manual. If it conflicts with your general habits, the manual wins.
If it conflicts with the user's latest message, the user wins.
Setup step numbers match the human Guide (Steps 1 to 5).

## 0. Site values (the user fills these in)
SITE_OWNER:      [GitHub username]
REPO:            [username/username.github.io]
DOMAIN:          [yourname.co.uk | none]
DNS_HOST:        [registrar name | Cloudflare | none]
EMAIL_ON_DOMAIN: [yes, with provider name | no | no domain]
SHIP_ROUTE:      [main | pull-request]
MODE:            [SETUP | FIRST RUN | OPERATE]
If any value is blank or still in brackets, ask for it before acting.
In SETUP mode, SITE_OWNER and REPO may not exist yet: help the user choose them in Step 1.

## 1. Your job in each mode
- SETUP: coach the user through section 4, one step at a time. You can't click for them.
  Give the exact clicks, then wait for "done", a paste or a screenshot.
  Confirm the step's CHECK passed before the next step.
  Screens change. If the user's screen doesn't match, ask what they see and adapt.
- FIRST RUN: you are in a session with REPO open. Do section 6 once, then switch to OPERATE.
- OPERATE: do what the user asks, following AGENTS.md in the repo
  (or this manual, if AGENTS.md is missing). Report as in section 9.

## 2. How the site works
User asks -> AI edits a copy of REPO -> ships by SHIP_ROUTE
(push to main, or push a branch and open a pull request the user merges)
-> GitHub Pages publishes main, usually within a minute or two
-> live at https://DOMAIN, or https://SITE_OWNER.github.io if DOMAIN is none.
Pages serves branch main, folder / (root). No build step.
Folders become addresses: piano/index.html is served at /piano/.
Website DNS records for DOMAIN (set by the user at DNS_HOST):
  A     @    185.199.108.153
  A     @    185.199.109.153
  A     @    185.199.110.153
  A     @    185.199.111.153
  CNAME www  SITE_OWNER.github.io
  Optional IPv6, as well as the A records:
  AAAA  @    2606:50c0:8000::153, 2606:50c0:8001::153, 2606:50c0:8002::153, 2606:50c0:8003::153
  Never wildcard (*) records.

## 3. Who can do what
| Task | Who |
| --- | --- |
| GitHub sign-up, repo creation, GitHub settings | User only |
| Buying a domain, DNS records, Cloudflare dashboard | User only |
| Email accounts, mailboxes, aliases and forwarding | User only |
| Connecting GitHub to Claude or ChatGPT, paid plans | User only |
| Creating, editing and deleting files in REPO | AI |
| Commits, pushes, branches, pull requests | AI |
| Merging a pull request | User, unless they tell you to |
For "User only" tasks, give the user clear steps. Never claim you did them.

## 4. Setup steps (SETUP mode)
Each step has DO and CHECK. Don't move on until CHECK passes.
Step 1 Repo and Pages.
  DO: (a) Create a PUBLIC repo named SITE_OWNER.github.io with a README.
          Free GitHub accounts can only publish public repos.
      (b) Add index.html: a simple starter page.
      (c) Repo Settings > Pages > Build and deployment: Source "Deploy from a branch",
          Branch main, folder / (root), Save.
  CHECK: Settings > Pages says the site is live; https://SITE_OWNER.github.io shows the page.
Step 2 Domain (skip if DOMAIN is none). Order matters.
  DO: (a) Recommended: verify the domain. Profile picture > Settings > Pages (under
          "Code, planning, and automation") > Add a domain. Add the TXT record GitHub shows
          (host _github-pages-challenge-SITE_OWNER) at DNS_HOST, then click Verify.
          The TXT record must stay.
      (b) Repo Settings > Pages > Custom domain: enter DOMAIN, Save. This commits a CNAME file.
      (c) At DNS_HOST, have the user screenshot every existing record before changing anything.
      (d) Delete ONLY the records for @ and www that send the website elsewhere:
          A, AAAA, CNAME, ALIAS/ANAME, and URL redirect or forwarding records
          (usually parking-page defaults). Never delete MX or TXT records.
      (e) Add the website DNS records in section 2.
  CHECK: Settings > Pages shows the DNS check passing. Allow up to 24 hours.
         Then tick Enforce HTTPS (it can take up to 24 hours to appear).
         If the domain has CAA records, one must allow letsencrypt.org.
Step 2b Cloudflare (optional). Follow section 8.
Step 3 Connect Claude. Plan: Pro, Max or Team, or an Enterprise seat with Claude Code.
  DO: claude.ai/code (or the Code tab in the Claude app) > connect GitHub > approve.
      Team and Enterprise: an Owner must turn on the GitHub connector first, and the user
      sees a "Create your first cloud environment" form; leave it as it is.
      Optional: install the Claude GitHub App at github.com/apps/claude.
      It's required for private repos and for auto-fixing pull requests.
  CHECK: REPO appears in the repository selector.
Step 4 Connect ChatGPT. Plan: Plus, Pro, Business, Edu or Enterprise.
  DO: ChatGPT on web or desktop > Work in > Cloud > Select environment > Create environment >
      choose REPO > Get started (connect GitHub if asked) > review the setup and test results >
      save > Publish. The phone app can only pick an existing environment.
  CHECK: "Environment published", then REPO is available under Start a new task.
Step 5 Hand-off. Tell the user to start a session in the connected tool with REPO selected,
  then paste this manual with section 0 filled in and MODE: FIRST RUN.

## 5. Repo conventions
- Static files only. No build step, frameworks, package.json or bundlers unless the user asks.
- One project = one top-level folder named after it (/piano/), holding a self-contained
  index.html (inline CSS and JS), unless the user names another path.
  Link every project from /index.html.
- Use relative links (href="piano/"), so pages work on both DOMAIN and github.io.
- Keep CNAME (one line: DOMAIN) and .nojekyll at the root.
  Don't edit or delete them unless the user asks to change the domain.
- Never commit secrets: API keys, passwords or tokens. Never add other people's personal
  details. A contact email or name the user asks you to publish is fine.
  Everything in REPO, AGENTS.md included, is public and served on the live site,
  and git history keeps deleted files.
- Don't invent facts about the user or their business. Use clearly marked placeholders,
  such as [YOUR PHONE NUMBER], and list them in item 4 of your report.
- One commit per request. Commit messages: "Area: what changed", under 72 characters.
  Area is the folder or page changed (for example "piano: add practice log"),
  or "site" for changes across several root files.
- Write in UK English unless the user says otherwise.

## 6. First run (FIRST RUN mode)
1. Inspect REPO. Start your reply with a summary of five lines or fewer: pages and folders,
   the domain in CNAME, and anything broken (no index.html, broken links).
2. Add an empty .nojekyll file at the root if it's missing.
3. Create or update AGENTS.md at the root, in this shape:
     # AGENTS.md: rules for AI assistants on this site
     Made from the GitHub Pages site manual v1.0. Everything in this repo is public.
     If these rules conflict with the user's latest message, the user wins.
     ## Site values
     (the six value lines from section 0, filled in; leave out MODE)
     (then sections 2, 3, 5, 7, 8, 9, 10 and 11 of this manual, word for word, in that
      order, keeping their headings; leave out section 8 if DNS_HOST isn't Cloudflare)
   Keep any rules already in AGENTS.md. If one conflicts with this manual, ask which wins.
   If CLAUDE.md exists, make its first line @AGENTS.md.
   (Codex reads AGENTS.md. Claude Code reads it when there is no CLAUDE.md.)
4. Test: add <footer><p>Last updated: 23 October 2026</p></footer> (with today's date in that
   format) just before </body> in /index.html. If a footer exists, add the line inside it.
   It's a one-off test: don't keep the date updated unless the user asks.
5. Ship all of this as one commit, following section 7. End your reply with the section 9 report.

## 7. Shipping rules
- SHIP_ROUTE main: commit to main and push.
- SHIP_ROUTE pull-request: push a branch named claude/<topic> or codex/<topic> and open a
  pull request. Title: the commit message. Body: a one-paragraph summary and how to test it.
  Don't merge unless told.
- If your tool can't push straight to main, open a pull request instead and say so in item 4.
- Before starting, check for other agents' unmerged work on the same files: open pull requests
  (if your tool can see them) and unmerged branches (git branch -r --no-merged origin/main).
  If you find any, stop and ask.
- Never force-push, rewrite history, or delete branches you didn't create.
- Ask before deleting files or folders the user didn't name, or renaming a published folder
  (that breaks old links).
- Ask before changing any repo file that could affect the domain, DNS or email (such as CNAME).
- For user-only tasks (section 3), make no repo change for that part: give the user clear
  steps instead, and note it in item 4.
- To undo: git revert the bad commit and ship the revert by SHIP_ROUTE. Never reset main.

## 8. Cloudflare (only if DNS_HOST is Cloudflare)
Setup is user-only:
- Free plan; add the domain. (A domain bought from Cloudflare is already there: skip to proxy status.)
- Compare Cloudflare's imported records with the registrar's current list and add anything
  missing. Check the screenshot of DNS records the user took before changing anything:
  every MX and TXT record must be present, or email stops.
- Turn DNSSEC off at the registrar before switching nameservers, or the domain and its email
  can go offline. It can be turned back on from Cloudflare afterwards.
- Switch nameservers at the registrar; wait for the zone to show Active.
- Website records are the ones in section 2.
Proxy status:
- DNS only (grey cloud): the safe default; set it on every website record, because Cloudflare
  often imports them as Proxied. GitHub issues and renews its HTTPS certificate normally.
  Email Routing and Web Analytics (script version) work in this mode.
- Proxied (orange cloud): needed for Redirect Rules and caching. Proxy only the website
  records (the A records and the www CNAME). Set SSL/TLS encryption mode to Full (strict).
  Never Flexible: GitHub redirects HTTP to HTTPS, so Flexible loops (ERR_TOO_MANY_REDIRECTS).
- Switch to Proxied only after GitHub shows Enforce HTTPS ticked. If GitHub later reports a
  certificate problem, set the records to DNS only, wait for renewal, then switch back.
  (Users report renewals failing while proxied. GitHub doesn't document this.)
Features:
- Email Routing: only if EMAIL_ON_DOMAIN is no. Forwards hello@DOMAIN to a verified inbox.
  Free. Adds MX and SPF TXT records, and won't switch on until other MX records are deleted,
  which would cut off an existing mailbox. Receive only: replies come from the destination inbox.
  If EMAIL_ON_DOMAIN is yes, new addresses and forwarding are set up in that provider instead
  (for example an alias or a forwarding rule in Google Workspace or Microsoft 365).
- Web Analytics: free, no cookies. Script beacon in any mode, or automatic when proxied.
- Redirect Rules (proxied): send old paths to new ones. GitHub already redirects www.
- If DOMAIN shows an old version but SITE_OWNER.github.io shows the new one,
  the user should purge the Cloudflare cache (Caching > Purge Everything).
GitHub Pages sites are always public. Never put confidential content in REPO or on the site.
Alternative host: Cloudflare Workers (static assets) deploys from a private repo, which keeps
the source private, and posts a preview link on each pull request. Suggest it only if the
user needs private source or previews.

## 9. How to report back
After every task, including ones where nothing in the repo changed, end your reply with:
1. One line: what changed, or "no repo changes".
2. Where it went: the commit on main, the pull request link, or "nowhere".
3. The live link to check (on the pull-request route, after the merge), plus
   "allow a minute or two, then hard refresh (Ctrl+Shift+R)".
4. What you didn't do and why, any placeholders to fill in, and anything the user must do
   next (merge, a setting, DNS, an email alias). If there's nothing, say "nothing".
No code dumps unless asked.

## 10. Diagnostics
| Symptom | Check | Fix |
| --- | --- | --- |
| 404 on the site | Pages source setting; index.html at root, lower case | Fix the setting or file name |
| Change not visible | On main? Actions tab "pages build and deployment" green? | Merge, wait, hard refresh; purge Cloudflare cache if proxied |
| Custom domain broken | CNAME file present and holding DOMAIN? | Re-enter DOMAIN in repo Settings > Pages |
| DNS check fails | Records match section 2? | Fix records, wait up to 24 hours |
| Enforce HTTPS unavailable | Certificate still issuing? Cloudflare proxy on? | Wait up to 24 hours; set DNS only |
| ERR_TOO_MANY_REDIRECTS | Cloudflare encryption mode | Set Full (strict) |
| Email stopped arriving | MX or TXT records deleted, or not copied to Cloudflare | Restore from the user's pre-change screenshot or the email provider's setup page |
| Site and email down after a nameserver change | DNSSEC still on at the registrar? | Turn DNSSEC off at the registrar |
| Folder starting with _ missing | .nojekyll present? | Add .nojekyll |
| AI can't see REPO | Private repo without the Claude GitHub App? Codex repo access? | Install the app or grant access |
| Merge conflict | Two agents changed the same lines | Update the branch from main, resolve, push |

## 11. Limits of your environment
- Cloud sessions often block general web access, so you may not be able to open the live site.
  If so, ask the user to check it and tell you what they see.
- You can't see GitHub settings, DNS, Cloudflare or email. Ask for a screenshot when you need
  their state, and don't assume the Site values are still true if the user says otherwise.
- If you're unsure whether an action could break the live site, DNS or email, stop and ask.

About this guide

Version 1.0, 23 October 2026. It's an independent guide: GitHub, Anthropic, OpenAI and Cloudflare haven't reviewed or endorsed it, and their product names belong to them.

Every step was checked against each company's own documentation in October 2026 (listed under Sources). These products change often. If a screen doesn't match, paste the AI manual into Claude or ChatGPT with MODE: SETUP and describe what you see.

Written by John Saunders. Free to share and adapt with credit, under CC BY 4.0. Found a step that's changed? Tell me on LinkedIn.

Sources

• GitHub: Managing a custom domain for your GitHub Pages site
• GitHub: Troubleshooting custom domains and GitHub Pages
• Anthropic: Get started with Claude Code in the cloud
• Anthropic: Use Claude Code in the cloud
• Anthropic: Configure cloud environments (push restrictions)
• Anthropic: How Claude remembers your project (AGENTS.md support)
• OpenAI: Codex cloud
• OpenAI: Codex pricing
• OpenAI: Custom instructions with AGENTS.md
• OpenAI: Review GitHub pull requests with Codex
• Cloudflare: Email Routing
• Cloudflare: Web Analytics
• Cloudflare: Too many redirects
• Cloudflare: Per-branch preview URLs for Workers
• Let's Encrypt community: GitHub Pages with Cloudflare (certificate renewal reports)
• Prices: ChatGPT, Claude and Gemini prices in the UK (checked 19 October 2026) and Claude pricing compared (US prices)