Simon Willison did not write a manual. He asked ChatGPT Work to write the manual about itself — and Hacker News spent the weekend arguing whether anyone should read it.
On August 30, 2026, Willison published Understanding ChatGPT Work — a human-written explainer that hit the front page (~257 points). In the comments he linked a follow-up artifact: codex-tool-reference.simonw.chatgpt.site, built from a single prompt in a fresh Work session:
Build a site that lists every one of your tools — nearly grouped into categories — and for each one explain what it does. Try to exactly duplicate arguments and tool descriptions where possible. Design aesthetic should be technical docs, minimal flare.
He later asked the same session to append all available skills. A codex.tools/reference snapshot captured the scale: 232 tool interfaces, 44 skills, and roughly 615,000 characters of skill source text — enough material that one HN reader called it "vomit of data" while another said it was the only way to see what actually ships out of the box.
For explainx.ai readers already on ChatGPT Work vs Codex or Codex as a platform, the site is less a tutorial than a reverse-engineered harness manifest — the closest public inventory of OpenAI's bundled agent stack.
TL;DR
| Question | Direct answer |
|---|---|
| What is it? | Vibe-coded reference site listing ChatGPT Work/Codex tools + skills |
| Who made it? | Simon Willison, inside a fresh Work session (not OpenAI official docs) |
| Scale | 232 tool interfaces · 44 skills · ~615k chars skill source (snapshot) |
| URL | codex-tool-reference.simonw.chatgpt.site |
| Key insight | Browser control is the control-browser skill + nodeRepl, not a standalone browser tool |
| Worth reading? | Yes if you design workflows; no if you only need one-off answers from the agent |
| Open-source alt? | Willison points to OpenClaw, Hermes, and self-hosted Codex Remote |
What the reference site contains
The site mirrors how OpenAI structures the harness internally — categories first, then tool schemas, then skill playbooks.
Tool categories (representative map)
| Category | What it covers | Why builders care |
|---|---|---|
| Runtime / files | Shell, file read/write, project paths | Local vs cloud boundary — see Work local vs cloud |
| Sub-agents | Delegation, parallel threads | Same orchestration pattern as Ethan Mollick's 2-hour bookmark scrape |
| Skills | Bundled SKILL.md workflows | Invoked with @ in Work, $ in Codex — agent skills guide |
| Plugins / MCP | Connectors + MCP servers | Overlaps explainx.ai's MCP security checklist |
| Web / image gen | Fetch, render, image tools | Distinct from Sites publishing |
| Automations | Scheduled / recurring Work tasks | Pairs with Codex slash commands |
| GitHub | 89 tools in the snapshot | Largest connector surface — repo, PR, issue, Actions |
| Gmail / Calendar | Mail and scheduling connectors | "Draft reply with attachment" workflows from HN threads |
| Sites | 23 tools | ChatGPT Sites collaborative editing |
| Data analytics | Spreadsheets, charts, analysis skills | Bundled skill suite, not one monolithic tool |
| Pets / Library | work-pets gamification, document library | Shows how OpenAI packages "delight" as first-class skills |
This is not a feature announcement — it is inventory. OpenAI's learn.chatgpt.com docs explain how to use skills and plugins; Willison's site answers what exists right now with argument-level fidelity.
The control-browser mystery — skills vs tools
The most cited takeaway from Willison's HN update: he could not find a tool named for headless browser control. The reference site's control-browser skill page explains why.
Pattern: the skill tells the agent to load Playwright documentation and drive the browser through the nodeRepl runtime tool — executing Node.js in a REPL rather than exposing browser_click as a first-class API.
That matches OpenAI's product split documented in Build skills:
- Tools — atomic capabilities with JSON schemas the model calls directly.
- Skills — packaged instructions (
SKILL.md) plus optional scripts/resources for multi-step workflows. - Plugins — installable bundles combining skills and MCP connectors.
Browser automation is a workflow (install deps, launch context, handle selectors, tear down) — so it lives in a skill, not a single tool. The same pattern shows up when Mollick's Codex run scraped X bookmarks: computer use + browser skills, not one "export_bookmarks" API.
For security-minded readers: any skill that reaches nodeRepl + Playwright is exactly the class of capability covered in MCP and connector hardening — broad tool access with policy enforced at the harness layer, not the skill text.
Notable bundled skills in the dump
These are the skills builders grep first when evaluating whether Work replaces a custom harness:
| Skill | Role |
|---|---|
| control-browser | Playwright automation via nodeRepl |
| sites-building | Publish and iterate ChatGPT Sites |
| data-analytics (suite) | Spreadsheet/chart workflows without pasting templates every chat |
| work-pets | Gamified agent companions — Codex pets guide |
| personal-context | Long-lived preferences and memory scaffolding |
| skill-installer | Bootstrap new skills from natural language |
| plugin-management | Install/list/configure plugins from inside Work |
Skills follow the open agent skills standard — same format explainx.ai documents in how to add skills to Claude, with four Codex discovery scopes: REPO, USER, ADMIN, SYSTEM.
"Why visit this instead of asking the agent?"
HN split cleanly on utility.
Skeptic view (matsemann): Any need is better served by asking the agent pointed questions — a 615k-character dump is unreadable and uncurated.
Willison's reply: "It's effectively the source code for ChatGPT Work. If you don't want to see that, don't visit it." His human-written Understanding ChatGPT Work post is the curated layer; the reference site is the raw manifest.
Practitioner view (mike_hearn): "It's useful to know what the actual feature set is out of the box."
explainx.ai's read: use both modes.
- Prompt the agent when executing — "attach the latest doc to this Gmail draft" does not require reading 232 tool pages.
- Read the reference when designing — before you rebuild a connector OpenAI already ships, before you write a skill that duplicates sites-building, or before you assume browser control is missing because no tool is named
browser_*.
The reference also helps compare hosted Work vs self-hosted alternatives. Willison notes OpenClaw, Hermes, and Codex Remote as DIY paths with the same primitives — VM, filesystem, browser — without the ChatGPT subscription wrapper. See OpenClaw 2.0 for the open-stack contrast.
Local Work vs cloud Work — why the inventory confuses non-devs
Willison echoed a thread concern from HN: ChatGPT Work (Cloud) on web/mobile runs remotely; ChatGPT Work (Local) in the desktop app touches the real filesystem and credentials. The UI does not always make that distinction obvious — yet the tool list blends cloud connectors and local runtime tools in one namespace.
If you are auditing what an agent can touch, the reference site is a checklist. If you are rolling this out to non-technical teammates, pair the inventory with explicit boundary setting — the same lesson from Cursor breach reports: capability maps are not permission policies.
How this fits the Codex / Work product map
| Layer | Reference site shows | Official docs | explainx.ai coverage |
|---|---|---|---|
| Modes | Shared tool/skill pool across Work + Codex | Work vs Codex help | Complete mode guide |
| Skills | 44 bundled SKILL.md sources | Skills & Plugins | What are agent skills |
| CLI | Same skills, $ invocation | Build skills | Slash commands reference |
| Platform | Tools exposed to app-server consumers | Codex as a platform | Harness embed guide |
| Import | N/A (snapshot only) | Import from Claude Code / Cursor | Plugin ecosystem |
OpenAI's August narrative — Codex as a platform, shared plugin directory, import-from-Claude — only matters if builders know what ships in the box. Willison's dump is the box label.
Actionable next steps for builders
- Skim categories, deep-dive one connector — If you live in GitHub, read the 89-tool GitHub section before writing custom MCP wrappers.
- Read control-browser before computer-use tasks — Understand nodeRepl constraints; compare to Work cloud browser sign-in.
- Cross-check skills you already wrote — Import from Claude/Cursor may duplicate bundled skills; use skills.lock patterns for reproducibility.
- Do not treat the site as stable API docs — Snapshot drift is guaranteed; verify tool names before production automations.
- Evaluate open alternatives with the same checklist — If you need local-only execution, map OpenClaw/Hermes tool surfaces against this inventory.
Related on explainx.ai
- ChatGPT Work vs Codex — shared quota and mode split
- Codex as a platform — open agent harness
- What are agent skills — complete guide
- Codex slash commands — CLI reference
- Ethan Mollick Codex bookmarks — long-horizon browser automation
- MCP security guide 2026
- OpenClaw 2.0 release
- How to add skills to Claude — three methods
Sources
- Simon Willison — Understanding ChatGPT Work (Aug 30, 2026)
- ChatGPT Work tool & skill reference site
- control-browser skill page
- Hacker News discussion — item 49504625
- OpenAI — Skills & Plugins
- OpenAI — Build skills
Tool counts (232 interfaces, 44 skills, ~615k characters skill source) reflect a codex.tools/reference snapshot and Simon Willison's August 2026 Work session output — not an OpenAI-maintained registry. Verify current capabilities in ChatGPT Work or Codex before production workflows. Follow @explainx_ai for harness coverage.