learn-codex-with-phoebe / Session 6 of 6
Learn Codex with Phoebe · Session 6 of 6

Power moves: automation, cloud, and beyond

Your site is live. The finale is about leverage: making Codex work while you're not at the keyboard - scripted one-shots, cloud tasks that run while your laptop sleeps, and the connections that make it all durable.

🔴 Hardest Builders 45 min live + self-study
0-3 · Welcome 3-16 · exec & scripts 16-31 · Codex cloud 31-45 · Connections & wrap
Part 0

The site works. Now make it work without you

Five sessions ago you installed a CLI. Now there's a live website on the internet with your name on it, an AGENTS.md that encodes your standards, skills that encode your taste, and a review habit that catches trouble before it ships. This last session hands you the multiplier: Codex in scripts, Codex in the cloud, and the routine that keeps your site healthy in ten minutes a week. Everything until now was you driving Codex. Today, Codex drives while you watch - or sleep.

Live - presented in session Self-study - read after class ★ Build-along demo The project: YOUR website
★ What you walk out with today A working codex exec health check for your live site, one cloud task delegated and merged, a weekly GitHub Action written and committed, and a ten-minute maintenance playbook. That's the whole course, closed with a bow - and the habits are yours for whatever you build next.
Part 1 · covers CLI developer commands / exec

codex exec - Codex in scripts 6 min live

Everything so far has been a conversation. codex exec is a sentence: one prompt in, work done, output back, no back-and-forth. That single change makes Codex scriptable - which means cron jobs, CI pipelines, and any maintenance task you'd rather never do by hand again.

LiveOne prompt, no conversation3 min

Interactive codex is for building - you steer, it works, you iterate. codex exec is for repeating: the task is fully specified up front, Codex runs it to completion, and the result lands in your terminal (or a log file, or a CI report). If you'd run the same prompt every week, it belongs in exec.

★ Three exec one-shots for your live site# the weekly classic - find what quietly broke codex exec "Check every internal and external link in this site's HTML files and report any broken ones as a markdown list with the file and line where each appears." # keep the site fast codex exec "Audit all images in this repo: list any over 300KB with their dimensions, and suggest the resize or format change for each. Report only - change nothing." # keep the site professional codex exec "Spellcheck the visible text of every HTML page. Ignore code blocks and proper nouns from AGENTS.md. Output a table: file, typo, suggested fix."
  • Where it shines: CI checks, cron schedules, pre-deploy gates, and any "look at everything and report" sweep - the boring, repeatable maintenance that never gets done manually.
  • The exec habit: say "report only, change nothing" when you want an audit. Unattended runs deserve tighter boundaries than conversations - you're not there to catch an enthusiastic rewrite.
  • Your standards still apply: exec reads the same AGENTS.md and skills as interactive mode. The taste you encoded in Session 3 rides along into every script.
LiveLevel up: a GitHub Action that runs your checks weekly3 min

The final form of exec thinking: don't run the health check yourself - have GitHub run it every Monday. And in the spirit of this whole course, you don't write the Action file. Codex does.

★ Ask Codex to write the ActionGoal: a GitHub Actions workflow that runs a weekly health check on this site. Context: this repo deploys to GitHub Pages. I care about broken links and files that accidentally get huge. Output: .github/workflows/site-health.yml that runs every Monday morning, checks all internal links and flags any file over 500KB, and opens an issue in this repo if anything fails. Add a short comment above each step explaining what it does. Boundaries: use only free, standard GitHub Actions features. Don't touch any other file. Explain how I enable and test it before I commit.
Treat the Action as a stretch goal Writing and committing the workflow file is today's job - Codex does it in one pass, and Demo 3 walks it. Actually enabling and watching it run needs GitHub setup time we don't have live, so that part is homework. The skill being taught is bigger than the file: any chore you can describe is a chore you can schedule.
Self-studyexec vs interactive - the decision in one table2 min read
exec or interactive: the decision in one tree Fully specified, repeatable? CODEX EXEC weekly checks, CI, audits INTERACTIVE CODEX taste, steering, debugging yes no Machines call exec for repeatable checks; weird problems still need a conversation.
🔍 Click to zoom - exec finds and repeats, interactive steers and debugs
SituationReach forWhy
Building something new, taste involvedInteractive codexYou need to see, react, and steer mid-flight
Same check, every weekcodex exec (or cron it)Fully specified up front - no steering needed
Gate in a CI pipelinecodex execMachines call it; the output is the artifact
Debugging something weirdInteractiveWeird needs conversation and reproduction steps
Audit-and-report sweep across the repocodex exec, report-only boundaryLong, boring, and perfectly repeatable
Part 2 · covers the Codex cloud docs

Codex cloud - delegate and walk away 7 min live

Everything until now ran on your machine, while you watched. A cloud task runs on OpenAI's machines, on a copy of your repo, while you do literally anything else - and comes back as a diff you review and merge. It's the difference between using a tool and having a teammate.

🧑 You CLI, app, or phone 📨 The task one GCOB ask, handed off ☁️ Cloud env works your repo, your AGENTS.md 📬 PR / diff back you review, then merge while this box runs, your laptop can be closed - or running two more tasks in parallel The loop is unchanged from Session 1 - goal in, verified work out. Only the machine doing the labor moved.
🔍 Click to zoom - the cloud handoff: you → task → cloud environment → reviewed diff
LiveWhat a cloud task is, and the three doors in3 min

You hand Codex a task; it spins up a cloud environment with your repo, works the same agent loop you know - read, plan, act, verify - and returns a diff or pull request for review. Your machine contributes nothing but the ask.

  • From the CLI: send a task to the cloud right from where you already work - build locally, delegate remotely, same session.
  • From the app: kick off and monitor tasks from the ChatGPT desktop app's Codex view.
  • From your phone: the one that changes behavior - remember "the showcase page needs a filter" on the train, delegate it from your pocket, review the diff after dinner.
  • Parallel is the superpower: fire three tasks at once - three hero layouts, three ways to structure the ideas page - and pick the winner. Sequential you becomes parallel you.
LiveCloud or local? The decision that matters2 min
Cloud or local? The decision that matters ☁ GO CLOUD Long, self-contained task Parallel experiments racing Away from your machine 💻 STAY LOCAL Iterating on taste, tight loop Needs something only your machine has Spec is fuzzy, needs conversation Cloud tasks share your 5-hour usage window with regular messages - one pool, not three.
🔍 Click to zoom - go cloud when the task is specified, stay local when it's still fuzzy
Go cloud when...Stay local when...
The task is long and self-contained ("add a 404 page matching the design system")You're iterating on taste and want the tight see-react loop
You want parallel experiments racing each otherThe task needs something only your machine has
You're away from your machine (or want to be)You're learning - watching the loop is the lesson
The change is well-specified and reviewable as a diffThe spec is fuzzy and needs conversation to find
Plus plan note Cloud tasks and code reviews draw from the same 5-hour usage window as your regular Codex messages - one pool, not three. Firing five parallel cloud tasks is spending five tasks' worth of that window at once. Fine when deliberate; surprising when not.
Part 3 · covers MCP overview + session continuity

Connections and continuity 5 min live

Three quieter features that make the loud ones durable: MCP plugs external tools into Codex, codex resume keeps long projects coherent, and plugins let your skills travel. Then it all folds into one weekly routine.

LiveMCP - giving Codex more hands2 min

MCP (Model Context Protocol) is an open standard for connecting agents to external tools and data - and Codex speaks it. Add a server to your Codex config and the agent gains that server's abilities: a filesystem server reaches folders beyond your project, an API server queries live services, a database server reads real data. Same protocol other agents use, so the ecosystem is shared.

Real world

A practical first server: connect a filesystem MCP server pointed at your notes folder, and "update my ideas page from this week's notes" stops requiring copy-paste - Codex reads the notes directly, drafts the update in your content-voice, and shows the diff. One config entry, one recurring chore gone.

Livecodex resume + plugins - continuity and sharing1 min
  • codex resume reopens a previous session with its context intact - the conversation about your showcase redesign survives the weekend. For a long-running project like your site, one continuing session beats twenty cold starts.
  • Plugins bundle skills for sharing - your $site-design-system and $content-voice from Session 3 live in .agents/skills as SKILL.md files, and a plugin wraps them into something a friend can install in one step. Your taste, portable.
LiveYour maintenance playbook - the weekly ten minutes2 min

Everything this course built compresses into one short routine. Same time every week - the site stays alive because the routine is too small to skip:

StepMoveMinutes
1codex resume - pick up your site session where it left off1
2codex exec health check - links, image sizes, typos (Part 1 boxes)2
3One content update - a new idea note, a showcase entry, a bio tweak4
4/review the change - the Session 5 habit, non-negotiable2
5Push - live site updated, laptop closed1
Why this works Dead personal sites die of ceremony - updating feels like a project, so it never happens. Ten minutes with an agent doing the labor removes the ceremony. The sites that stay alive are the ones that are cheap to touch.
Part 4 · the send-off

Where you go from here 2 min live

The website was never the point. It was the excuse to build habits that transfer to everything.

LiveWhat transfers, and what to build next2 min
  • What you now know travels: the agent loop (goal → context → action → verified result), GCOB, the AGENTS.md and skills standard, and the review-before-ship habit. Point them at any repo, any project, any job - they work the same.
  • Next builds: a second site (for a project, a team, a family thing - you'll be shocked how fast round two goes), a small tool that scratches a real itch, or the big one: automating a chore from your actual work with exec and a skill.
  • Keep learning where it's current: OpenAI Academy's Codex for Builders goes deeper on automation and team workflows, and the official docs changelog at learn.chatgpt.com is the real curriculum now - Codex ships fast, and the changelog is where the new power moves appear first.
Demo 1 of 3

exec health check on your live site ★ 8 min · everyone runs it

From your site folder, run the link checker from Part 1: codex exec "Check every internal and external link..." - watch it work with no conversation, just output.

Read the report together. Most sites have at least one surprise - a renamed file, a moved anchor, an external link that died since Session 5.

Fix ONE finding, interactively: switch to regular codex, paste the finding, let it fix, /review, push. Broken link found by script, fixed by conversation, live in minutes.

Say the pattern out loud: exec finds, interactive fixes. That division of labor is the whole automation mindset.

Demo 2 of 3

Delegate to the cloud, close the lid ★ 10 min · the finale's showpiece

Kick off a cloud task: "Add a 404 page that matches my design system - same header, same palette, a friendly 'that page wandered off' message, and a link home. Follow AGENTS.md and the $site-design-system skill."

Confirm the task is running in the cloud. Then - deliberately, theatrically - close the laptop lid. Count to ten with the room. Codex is working right now, on a machine that isn't this one.

Reopen. Check the task: when it's done, read the diff like you learned in Session 5 - does the 404 page actually match your design system? (It read the same skills. It should.)

Merge it, pull, push if needed - then visit a nonsense URL on your live site and meet your new 404 page.

Real world

The lid-close is not a gimmick - it's the mental model shifting in real time. Every previous session, closing the laptop stopped the work. This time it didn't. People remember the ten seconds of the closed lid longer than any slide in the course.

Demo 3 of 3

Write the weekly Action ★ 5 min · commit it

Run the GitHub Action prompt from Part 1 - Codex writes .github/workflows/site-health.yml with commented steps.

Read the file with Codex as your guide: "Walk me through this workflow line by line - when does it run, what does it check, what happens on failure?"

Commit and push it. Enabling and watching the first run is homework - but the file is real, in your repo, written by describing what you wanted. A robot now guards your website's health.

After the session

This week - and after ◐ 45 min total

That's the course 🎓 Six sessions ago the website lived in your head. Now it lives on the internet, checks its own health, and updates in ten minutes a week - and you learned to work with an agent along the way, which is the skill that outlasts any single tool. Go build the next thing. Phoebe is proud of you, and honestly, so is Codex.
Check yourself

Three questions before you graduate 🎯 ◐ 90 seconds

1 · When does codex exec beat interactive codex?

exec is one sentence, not a conversation: perfect for checks you'd run every week, wrong for taste-driven building. exec finds, interactive fixes.

2 · Best candidate for a cloud task instead of local work?

Cloud shines when the spec is clear and your presence adds nothing - long tasks, parallel experiments, or when you're away. Fuzzy taste work wants the local loop.

3 · On a Plus plan, what draws from the same 5-hour usage window?

One pool, not three. Five parallel cloud tasks spend five tasks of window at once - great when deliberate, surprising when not.

Source material

Official sources covered

This session teaches the working content of OpenAI's official materials - docs at learn.chatgpt.com and free courses at OpenAI Academy.

CLI developer commands / exec (official docs)non-interactive runs, scripting, CI patterns - Part 1 + Demo 1
Codex cloud (official docs)cloud tasks, parallel runs, CLI/app/phone kickoff, Plus limits - Part 2 + Demo 2
Codex for Builders (OpenAI Academy)the automation portions - exec workflows, delegation habits - Parts 1-3
MCP in Codex (official docs)working overview + one practical server here; full config depth is docs territory

Session 6 cheat sheet · pin this forever

codex execOne-shot, no conversation: codex exec "check all links and report". For CI, cron, weekly sweeps. Say "report only" for audits.
exec vs interactiveexec finds, interactive fixes. Fully specified + repeatable = exec. Taste + steering = interactive.
Cloud tasksDelegate from CLI, app, or phone; Codex works on a copy of your repo in the cloud; a diff/PR comes back. Parallel tasks = superpower.
Plus windowMessages + cloud tasks + code reviews share ONE 5-hour pool. Parallel tasks spend it faster - be deliberate.
Continuity kitcodex resume (session survives the weekend) · MCP servers in config (more hands) · plugins (skills, shareable).
Weekly 10 minutesresume → exec health check → one content update → /review → push. Cheap to touch = stays alive.