Gnothi Claude Code

A working session on a Next.js and Postgres project is used to demonstrate moving repeated instructions — formatting, migration safety, route-handler conventions — out of prompts and into hooks, slash commands, skills, subagents, and MCP servers, followed by a rundown of recent Claude Code releases and model updates.

Episode page & show notes

Visit website

Turning repeated instructions into repository rules

The chapter walks through five places to put an instruction so it stops living in the same three sentences typed at the top of every session. A hook is a shell command wired to a fixed point in the loop — format the changed file and run the typecheck after every write, no memory required — and the Claude Code hooks documentation covers how they can also block an action outright, which is distinguished from a flat permissions deny rule by the fact that a hook can inspect state before refusing. A custom slash command turns a retyped personal habit, like a pre-commit diff review, into a named file the whole team shares. A skill goes further: a folder whose short description is always visible but whose full body — doctrine plus a real example file — only loads when the work actually matches, exactly as laid out in the Claude Code skills documentation. A one-off subagent handles the heavy-input, light-output question — search forty files, report three paragraphs — per the Claude Code subagents documentation. And an MCP server connects to a system outside the repo entirely — an issue tracker, a read-only database — as described in the guidance on connecting Model Context Protocol servers, best added only for a system you keep pasting from. The chapter closes on the risk of over-wiring — too many hooks, skills and servers making a failure's cause unreadable — and the fix of stripping back to a bare session and re-adding one layer at a time.

This week's releases

A short rundown of recent changes: a new diagnostic command flags which skills are eating context, new models default to a million-token window with a much cheaper cache-read price, and a supply-chain fix stops a cloned repo from silently redirecting a client's configuration.

This chapter builds a layered permissions system for coding sessions — allow, ask, and deny rules split across user, project, and local settings files — so routine actions stop requiring attention while irreversible ones still get a pause, then extends the idea into plan mode and a rundown of recent tool updates.

Episode page & show notes

Visit website

The founding charter

The core problem: every permission prompt spends a little of your attention, and by the thirtieth approval in a session you've stopped reading before you say yes. The fix isn't discipline — it's deciding, calmly and in advance, what a session may do freely, what it must ask about, and what it may never do, written into a file rather than negotiated in the moment.

That file lives in three places, layered from general to specific: a user-level settings file that travels with you across every project, a committed project-level file that belongs to the whole team and shows up in code review, and an uncommitted local file for machine-specific quirks. More specific layers override broader ones, though a managed policy file (the kind an IT department deploys) sits above all of them and can't be overridden.

Inside these files, permission rules sort into three lists. Allow lets a matched action through without a prompt — pure convenience, buying back attention for boring, repeatable calls like running tests or reading files. Deny blocks an action outright with no prompt and no override, reserved for anything irreversible: touching production data, reading credentials, force-pushing or rewriting git history. Ask sits in between and always interrupts. Deny beats everything; ask beats allow. Applied to a typical TypeScript/Next.js/Postgres project, this produces a short, deliberate file — narrow allow rules for test, typecheck and lint commands, ask rules for writes outside the repo and package installs, deny rules for env files, cloud credentials, and destructive git or database commands.

The payoff is counterintuitive: locking things down doesn't feel restrictive, it makes the prompts that remain actually mean something, because the noise is gone.

The same logic scales up through plan mode, which stops a session from editing anything while it reads, traces and proposes — useful for unfamiliar code or multi-file changes, skippable for one-line fixes. An approved plan is not a contract; work in progress can reveal files the plan never listed, so the habit is to compare the plan's file list against what actually changed. Built-in commands like permissions, config, context, and status let you inspect and edit the live configuration mid-session rather than restarting — which matters because configuration drift is real: a rule quietly added to a local file weeks ago can silently override what the team believes is running. Checking the resolved permissions at the start of a session catches this before it costs anything.

The show's news beat, skewed hard

A new restricted mode for the command-line tool strips out command execution, code running and web fetching, and confines edits to the working directory — and it ignores your settings files entirely, offering a hard ceiling for working with untrusted code. Authentication can now log in directly against console billing alongside SSO and email options. Smaller additions include a readline-style keybinding option, per-prompt frontmatter controls for effort level and cache duration, and a statusline metric exposing rolling five-hour and seven-day rate-limit usage. A native VS Code extension brings inline diffs and sidebar progress, and community projects bundling sub-agents, skills and hooks — including one collection called Everything Claude Code and a planning-focused framework called Superpowers — offer working examples of the extension layer ahead.

This chapter walks through running a single Claude Code session end to end on a real app — writing a strong first prompt, reading and correcting the model's plan, building a trustworthy project memory file, and cleanly resuming work the next day — then closes with a roundup of recent pricing, rate limit, and SDK changes.

Episode page & show notes

Visit website

Learning your codebase, one session at a time

The core of this chapter is a single hands-on walkthrough of running one Claude Code session properly, using an ordinary TypeScript/Next.js app with Postgres behind it as the running example. It opens with the problem of a session that keeps rediscovering the same facts about a repository — how to run the tests, where things live — because nothing was ever written down for it to read. From there it builds out a full first prompt: naming the goal in outcome terms, scoping what not to touch, pointing at the real files or an existing pattern to imitate, and stating a concrete done-condition such as a test that fails without the change. It covers how to read the plan that comes back — checking the file list, the silent assumptions, and whether the approach matches the project's actual conventions — and makes the case for interrupting the moment an assumption is wrong rather than after several files have been built on top of it.

From there it turns to project memory: generating a starter file with the init command, then cutting it down to only what's true and verified — real commands, real layout, real conventions — while stripping out prose, philosophy, and anything nobody will maintain. It explains how these memory files stack rather than override each other, how nested files load lazily, and how imports work. It closes with finishing a unit of work cleanly and picking it back up, covering the continue and resume flags, the from-pr option, and the naming and forking commands that make sessions easier to find again.

This week in Claude Code

The main item is pricing: Sonnet 5's standard rates are now set at $2 per million input tokens and $10 per million output tokens, cancelling a planned increase, alongside removal of peak-hour throttling and doubled five-hour rate limits on paid plans.

A recent changelog entry adds separately configurable prompt cache lifetimes for main sessions and subagents, finer usage telemetry, an organisation-configurable model picker, and a fix for remote tool servers dropping their connection in print mode. Recent releases also brought a design-drafting command preview, a Concise output style, persistent goal conditions across resumes, and an environment variable for setting a default model. On the SDK side, the Python Agent SDK picked up in-process Model Context Protocol server support and a structured error type, and the platform Python SDK reached version 1.0 on a new HTTP transport.

A hands-on walkthrough of driving Claude Code on a real codebase — writing and maintaining a project memory file, running a scoped bug fix from request to committed diff, and resuming sessions the next day — followed by a quick roundup of recent CLI, desktop, and SDK releases.

Episode page & show notes

Visit website

The founding charter

The core loop for driving Claude Code by hand: open a session in your project, ask for a change in plain English, review the diff, run tests, commit. The real subject is the gap between a session that starts cold and one that already knows your codebase, and how a request that names a file, a current behaviour, a wanted behaviour, and a constraint outperforms a vague ask, because the model fills any gap with its own taste rather than yours.

That gap gets closed with a Markdown memory file, written by running the in-session init command, which surveys the package manifest, test setup, build, and git history before drafting instructions. The file should stay short: how to run the app, how to run the tests, and two or three conventions a new contributor always gets wrong — nothing derivable by reading the code. These files stack from broadest to most local at session start, and the automatically maintained per-project memory file is capped at roughly two hundred lines or twenty-five kilobytes, while everything else is not.

A worked example — moving email validation from submit-time to on-blur — shows the loop end to end: Claude reads the form and schema, proposes a scoped fix, runs the test command from memory unprompted, surfaces a failing existing test, and waits for a human call on which behaviour is correct. The diff stays small because the request stayed narrow.

Sessions persist as transcripts on disk automatically, restarted with a continue flag for the most recent one or a resume flag for a picker across past sessions, with branching and renaming available mid-session — though transcripts older than thirty days get cleaned up by default. The closing warning: an unmaintained memory file rots into a wiki of contradictory, stale instructions that Claude will obey confidently anyway, so it needs treating as short, living, and checked every quarter.

The show's news beat, skewed hard

The current CLI release adds a per-loop breakdown to the usage command and separate cache lifetime settings for main sessions versus subagents, plus a model-picker setting and managed pricing for enterprise contracts. Recent releases also fixed lost plan-mode state on restarted remote workers and added automatic resumption after a rate limit, with a matching auto-continue toggle on the desktop app's limit notification. A research-preview design command now opens an editable canvas for implementing frontend interfaces, and the Python SDK has hit version one with a CLI migration helper for teams still on the old client conventions.

This chapter walks through moving Claude Code's automated runs off GitHub's shared machines and onto a runner living inside a private AWS network, covering the setup, the trade-offs against self-managed runners, and the most common way such a setup silently stalls, then closes with a roundup of recent Claude Code releases and pricing changes.

Episode page & show notes

Visit website

Getting a runner inside your own network

The problem is simple to state: a workflow can label an issue, wake Claude Code, have it read your repo and instructions, write code, run tests, and open a pull request — all cleanly — and then stop dead the moment it needs something only your own network can give it. A database in a private subnet, an internal service, a preview deploy: none of it is reachable from a machine sitting on GitHub's own infrastructure, because that's exactly how private subnets are supposed to work.

The fix is ownership of the machine itself. A GitHub Actions runner never gets connected to — it phones out, holds an outbound connection open, and waits for work. That means it can sit deep in a private subnet with no route to the internet and still pick up jobs, and everything the job then does reaches out from inside your network.

Two ways to get there are laid out and compared directly: letting AWS CodeBuild's runner mode spin up a container per job and throw it away when done, or standing up and registering your own instances or Kubernetes pods. The recommendation is the managed option for almost everyone, with real per-minute and startup-time figures backing the trade-off, plus a full walkthrough — connecting the account to GitHub, creating the project, wiring subnets and a NAT path with interface endpoints, the exact runs-on label syntax the run identifier and attempt number require, authenticating through the project's own role versus an explicit federated handshake, and why ephemeral runners matter (a permanent, non-ephemeral runner can quietly hand one job's leftover cloud credentials to the next). It closes with the single most common failure — a job stuck silently "waiting for a runner" — and the two-minute check for it: the label, then the webhook delivery log.

What shipped recently

A short round of Claude Code updates, several of which land right on this setup. The self-hosted runner command gained a shutdown-delay flag and two ways to supply proxy authorization, relevant the moment runners sit behind an authenticating proxy in a locked-down subnet. The same release fixed prompt caching for gateways using a custom base address, and fixed a memory leak in long unattended sessions. The introductory Sonnet 5 pricing has been made permanent, cancelling the planned September increase. Two default behaviors changed — todo/task-tracking tools are now off by default, and forked subagents are now the default — each with an environment variable to reverse it. The bundled API skill was cut from over 200,000 tokens of context down to roughly 25,000. And the temporary boost to weekly usage limits has expired.

Every GitHub Actions primitive is the automated substitute for a human's presence, so when nobody's at the keyboard you must declare a tight timeout-minutes (the default is a six-hour burn) and an explicit permissions block. We walk the full workflow anatomy, triggers, secrets, GITHUB_TOKEN scopes, and end-to-end AWS OIDC auth for a Claude Code run.

Episode page & show notes

Visit website

Act III opens with the CI plumbing under every headless Claude Code run. The frame: each GitHub Actions primitive covers a failure mode a human would otherwise handle live. Claude Code GitHub Actions is built on the Claude Agent SDK and runs on GitHub's own runners.

News

Tutorial: GitHub Actions foundations

Wire every parallel Claude Code session, subagent, and headless run into one OpenTelemetry feed and watch per-agent token burn and dollar cost on a Grafana dashboard, with stall detection that catches a looping agent before it drains the budget. The one trap: the same opt-in log flags that give you attribution can ship raw prompts and pasted credentials to your observability backend, and one shared API key collapses every worktree's cost into a single lying bucket.

Episode page & show notes

Visit website

This week's Claude Code releases, then a full tutorial on fleet observability and cost dashboards for parallel runs.

News (2026-06-26 to 2026-07-03, from the Claude Code changelog):

Tutorial - Fleet observability and cost dashboards:

Apply one named label to an issue and Claude Code runs an unattended implement pass that pushes a branch and opens a PR. The label gates who can fire it, not who wrote the issue body, so the spec you splice into the prompt is still attacker-controllable and you must treat it as data.

Episode page & show notes

Visit website

A hands-on tutorial on wiring anthropics/claude-code-action so that applying a GitHub label kicks off an implement pass with no @claude mention. Plus the week's Claude Code news.

News (June 21-25, 2026)

Tutorial: label as the trigger

Once a headless Claude run passes, the last rung is delivery: branch, commit, push, and open the PR with nobody at the keyboard. The trap that bites everyone is the PR whose own CI never runs, because GitHub won't trigger workflows for events made by the default token.

Episode page & show notes

Visit website

Act II continues. We turn a passing headless Claude Code run into an open pull request with no human at the keyboard, and we walk straight into the pitfall that breaks most first attempts.

News (June 17–21, 2026):

Tutorial — Auto-PR:

Prevention sometimes fails, so engineer the blast radius: layer scope limits on permissions, credentials, network, accounts, spend, and merge rights so one bad turn stays cheap. The trap is assuming "it only opens a PR" is safe, because a PR triggers CI that can hold your secrets.

Episode page & show notes

Visit website

A two-part episode for people running Claude Code unattended.

News. Anthropic shelved the planned Agent SDK and claude -p billing split on June 15, the day it was due to land, telling customers "nothing changes for now" and promising a reworked plan with advance notice (The New Stack, digitalapplied, the-decoder). Headless and SDK usage keep drawing from your subscription pool, so don't migrate automation to API keys for this reason. v2.1.178 adds Tool(param:value) permission rules (e.g. Agent(model:opus)), nested .claude/skills auto-load, and runs subagent spawns through the auto-mode classifier (changelog, release). v2.1.179 is fixes only: mid-stream drop recovery, WSL2 scroll restore, and a sandbox glob fix on Linux. Backdrop: short outages and elevated Opus 4.8 errors (StatusGator, TechTimes).

Tutorial: blast-radius engineering. The prior episode built layers that prevent a bad action. This one assumes prevention fails and bounds the damage. Defense in depth across five layers:

The pitfall: "it only opens a PR" ignores pull_request_target, which runs fork code with base-repo secrets (2i2c, OpenSSF). See the spotipy and openlit advisories.