OCDevel Claude Code

OCDevel

Take Claude Code from its first useful change in your terminal to a repeatable software delivery workflow. For working developers who already ship applications and use Git, this course starts with setup, giving Claude a task, inspecting the diff and checking the result. Build on that session with project instructions, skills, hooks, MCP connections and context management. Later lessons connect parallel agents and Git worktrees to GitHub issues, pull requests and review-and-fix loops, then develop testing and deployment workflows with GitHub Actions and AWS. Permissions, sandboxing, cost controls and observability are taught alongside the automation they support, so you can judge what a run changed and investigate a failure. Concrete examples explain the commands, settings and checks behind each workflow; earlier techniques return as parts of larger systems. Claude Code news and practical shortcuts cover changes that affect coding work, setup or cost. The curriculum builds toward an issue-to-deployment pipeline, including rollout decisions and incident response. This show's audio is narrated by an AI-generated synthetic voice.

Play

Open in

26 episodes
English

Episodes 26

Newest Oldest Longest

All20 Unplayed20 In progress0 Played0

Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.

Saturday · length unknown
Writing the Instructions Your Next Session Will Actually Read
This chapter explains how to write and test a CLAUDE.md file so a fresh Claude Code session knows a project's commands, layout, and definition of done without being told each time, and covers a recent change to which parts of a session actually read that file. Episode page & show notes Visit website The founding charter The core of this chapter is CLAUDE.md, the file Claude Code loads automatically at the start of every session before your first request arrives — no attaching, no pasting, just a file sitting at the project root or inside the .claude directory that gets read on its own. It walks through the four places instructions can live — the shared project file, a personal file in your home directory, an untracked local variant, and organization-wide settings — and explains that Claude Code doesn't let the narrowest file override the others; it concatenates all of them into context, broadest first, and leans on the model to treat the more specific instruction as the one that wins. From there the chapter builds an actual file for a shared-list app: starting from a /init draft, keeping only the commands that aren't obvious (the dev server, the type check, the one authoritative test command), naming the manual click-through journey that tests alone can't replace, writing down two or three real architectural constraints, and stating flatly what "finished" means. It explains why the file should stay short — it's re-injected on every turn, so bloat taxes every future question — and points to /context, /doctor, and /memory as ways to check what's loaded and trim what doesn't earn its place. It draws a hard line between guidance, which the model can still talk itself past, and real enforcement through a permissions deny list, and closes with a repeatable loop for testing whether an instruction actually changes agent behavior: fresh session, one-line request, watch what's skipped, edit one sentence, retest. What changed in how instructions get loaded A shorter section covers a real gap in that mental model: the built-in Explore and Plan subagents skip reading CLAUDE.md and skip checking Git status entirely, while custom subagents you define still inherit it. It also notes a new flag for passing subagent rules via a file instead of a command-line string, and a fix in recent releases removing an approval prompt that used to stall scripted runs using organization-delivered instructions — all catchable with the same /context check.
Thursday · length unknown
Your First Real Change, Made by an Agent and Checked by You
This chapter installs Claude Code, opens it inside a small shared-list web app, and walks through fixing one real bug — blank items being addable — end to end: describing the project, requesting a narrow change, reading the diff, running tests, manually verifying the behavior, adding a test, and committing. It closes with two recent changes to the tool, Auto permission mode and default model updates, and what to check about each. Episode page & show notes Visit website Getting the tool onto your machine The chapter walks through installing Claude Code as a standalone application rather than through npm, explaining why the native installer (fetched with curl or the PowerShell script) is the recommended path — it updates itself and needs no Node.js runtime — while noting Homebrew, WinGet, and Linux package repositories as valid alternatives, per the setup instructions. It covers system requirements, the sign-in flow through a browser, and the built-in diagnostic reached with slash doctor for fixing installation and network problems, drawn from the CLI reference. Opening a real project Once launched inside a small shared-list web app, the chapter shows the workspace trust prompt, the live session display showing model and context usage, and the two permission modes — Manual, which asks before every write or command, and Auto, now the default for Pro, Max and Team plans, which only interrupts for destructive operations. It draws on the permissions documentation and the interactive mode guide to explain what each mode actually shows you and why reading a diff before approving it matters. Making one change and proving it The core of the chapter is a single fix: stopping blank or whitespace-only list items from being added. It shows the tool describing the project first, proposing a small diff, running the test suite after a command-approval prompt, and then a manual click-through of the app to confirm the behavior actually changed — because a passing suite only proves what it already tested. A new test is added, deliberately watched failing and then passing, before a single readable commit closes the loop. What changed recently in Claude Code A short section flags two changes that affect a first session directly: Auto mode becoming the default permission mode on Pro, Max and Team plans, and Sonnet 5 becoming the default model with support for pinning a default model via environment variable, both listed in the Claude Code changelog and the what's new page.
September 5 · length unknown
Moving the Instruction Out of the Prompt
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.
August 29 · length unknown
Deciding What a Session Is Allowed to Do
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.
August 25 · length unknown
One Session, Driven by Hand
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.
August 25 · length unknown
A Session That Already Knows Your Project
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.
August 23 · length unknown
Moving your unattended Claude Code runs onto a runner inside your own AWS account
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.
July 8 · length unknown
GitHub Actions Foundations for Unattended Claude Code Runs: Triggers, Permissions, OIDC, Timeouts, and Concurrency
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 Claude Code CLI v2.1.204 (Jul 8): single-change release fixing hook events not streaming during SessionStart hooks in headless sessions, which could idle-reap remote workers mid-hook. Safe to keep heavier SessionStart hooks again. (changelog, Releasebot) claude-code-action v1.0.166 (Jul 6): drop buffered inline comment when posted live (#1412), modern noreply co-author email (#1369), symlinked CLAUDE.md config snapshot (#1441), preserve repeated --add-dir (#1256), propagate curl install failures (#1241). (release notes) CLI v2.1.202 (Jul 6): Dynamic workflow size in /config; workflow.run_id / workflow.name OpenTelemetry attributes; /review back to single-pass, multi-agent moved to /code-review. CLI v2.1.200 (Jul 3): default permission mode now labeled "Manual" — set an explicit --permission-mode in CI. Tutorial: GitHub Actions foundations Workflow anatomy (on, permissions, jobs, runs-on, steps). Triggers: workflow_dispatch, schedule/cron (UTC, 5-min min, default-branch only, 60-day public auto-disable), repository_dispatch, issues/pull_request (synchronize), workflow_call. Jobs run in isolated VMs — matrix, needs, if, and outputs pass state. Secrets vs variables vs environment secrets. The Feb 2023 read-only GITHUB_TOKEN shift and the permissions: allowlist (unlisted scopes become none; id-token: write required for OIDC). Full AWS OIDC auth with the sub-claim security lever. Concurrency groups, timeout-minutes (360-min default), and caching. Pitfalls: GITHUB_TOKEN can't trigger downstream CI, silent 403s, pull_request_target injection, the 6-hour burn, fork PRs lack secrets, OIDC sub mismatch, and silently disabled crons. Pin actions to full SHAs.
July 3 · length unknown
Fleet observability for parallel Claude Code: built-in OpenTelemetry, Grafana cost dashboards, and per-agent spend attribution
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): Claude Sonnet 5 is now the default (v2.1.197, Jun 30): native 1M-token context, promo pricing $2/$10 per Mtok through Aug 31. Shows in /model. (Some trackers misdate it to Jul 1 - the docs changelog is authoritative.) Background subagents by default (v2.1.198, Jul 1): agents keep running and notify on finish; claude agents runs now commit, push, and open a draft PR from a worktree; Notification hook fires agent_needs_input/agent_completed; Explore agent inherits the session model (capped at opus); new /dataviz skill; the /agents wizard was removed. Stacked skills + retry controls (v2.1.199, Jul 2): /skill-a /skill-b loads up to 5; CLAUDE_CODE_RETRY_WATCHDOG raises retries to 300; fixed subagents reporting usage-limit errors as success, plus a Linux daemon that killed all agents every ~50s. Org defaults + durability (v2.1.196, Jun 29): admin org default model, stream idle watchdog on by default, background sessions survive restarts. Tutorial - Fleet observability and cost dashboards: Native OpenTelemetry, opt-in via CLAUDE_CODE_ENABLE_TELEMETRY=1 - Monitoring docs. Metrics like claude_code.cost.usage, claude_code.token.usage, claude_code.active_time.total; log events; beta trace spans (claude_code.interaction root). Reference stack: ColeMurray/claude-code-otel (Collector to Prometheus + Loki to Grafana, six-section dashboard). Cost tools: /cost slash command (Manage costs); ccusage (npx ccusage@latest, ccusage blocks --live); org-level Usage and Cost API and the per-user Claude Code Analytics API. Headless mode: claude -p --output-format json returns total_cost_usd, num_turns, session_id; guard with --max-turns and --max-budget-usd. AWS worked example: Analyzing Claude Code usage with CloudWatch and OpenTelemetry. Pitfall: OTEL_LOG_USER_PROMPTS=1 / OTEL_LOG_TOOL_DETAILS=1 leak prompt text and credentials (Elastic Security Labs); one shared API key breaks per-worktree attribution.
June 25 · length unknown
Label-Driven Runs: Trigger a Claude Code Implement Pass From a GitHub Label
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) claude-code-action: v1.0.157, v1.0.156 (June 24), v1.0.155 (June 23). Merged fixes per the releases page: filter PR reviews/inline comments to trigger time (#1385), allow @ in branch names (#1411), format-turns content-type fallback tests (#1421). Bump to v1.0.157. CLI v2.1.191 (June 24): new /rewind to recover a session cleared with /clear; stopped background agents stay stopped; comma-separated hook matchers fixed; MCP retry logic; ~37% lower streaming CPU. CLI v2.1.187 (June 23): new sandbox.credentials setting blocks sandboxed commands from reading secrets, org model restrictions, remote MCP 5-min idle timeout (CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT), /install-github-app workflow setup now optional. Billing: the planned move of Agent SDK / Claude Code usage onto a separate credit is NOT taking effect; being reworked with advance notice. Tutorial: label as the trigger GitHub fires a labeled activity on the issues event. Use on: issues: types: [labeled] and gate with if: github.event.label.name == 'claude-implement' — without the if, every label burns a run. See Events that trigger workflows. Two gates: the action's label_trigger: "claude" input, or workflow-level types: [labeled] + an if. v1 auto-detects automation mode when you set an explicit prompt. v1 consolidated inputs: direct_prompt/override_prompt/mode → prompt; model/max_turns/allowed_tools/custom_instructions → claude_args. Pin @v1, not @beta. Known bug #210: early label_trigger failed on a missing LABEL_TRIGGER env mapping. PRs aren't auto-created (per the action's security docs): Claude pushes a branch and links the PR page. Wire gh pr create yourself. GITHUB_TOKEN can't fire downstream workflows (docs, #25565): a default-token PR won't start CI, and a bot-applied label won't fire the labeled workflow. Use actions/create-github-app-token@v2. Label as a state machine: claude-implement → remove first, add claude-working → claude-done/needs-human. Idempotent + a concurrency group keyed on issue.number. See gh issue edit. The pitfall: splicing issue.body into the prompt is the lethal-trifecta injection surface. The label gates who labels, not who wrote the body. Gate authors, treat body as data, shrink blast radius. Cron alternative: poll with gh issue list --label, run headless claude -p. See the GitHub Actions docs.
June 21 · length unknown
Auto-PR Workflows: Turning a Green Headless Run Into an Open Pull Request
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): v2.1.183 — Auto mode now blocks destructive git commands you didn't ask for (git reset --hard, git checkout -- ., git clean -fd, git stash drop), blocks git commit --amend on commits it didn't make this session, and guards terraform destroy / pulumi destroy / cdk destroy. New attribution.sessionUrl setting omits the claude.ai link from commits and PRs. New /config --help; in the toggle, Esc now SAVES. v2.1.181 — /config key=value inline from the prompt (works in -p and Remote Control), sandbox.allowAppleEvents, CLAUDE_CLIENT_PRESENCE_FILE to mute mobile pings, bundled Bun 1.4, line-by-line streaming, auto-retry on dropped connections. v2.1.185 — Stream-stall hint reworded and now fires after 20s instead of 10s. Tutorial — Auto-PR: Two homes for the logic: a local/cron bash script wrapping claude -p then git + gh, or a GitHub Actions workflow governed by permissions:. Prefer a deterministic shell GATE (tests green? non-empty diff? existing PR?) and scope Claude to the edit. Headless docs, CLI reference. Always git push -u origin <branch> before gh pr create — the push prompt is fatal with no TTY. Actions needs contents: write AND pull-requests: write; missing the second is a silent 403. The big one: PRs opened with the default GITHUB_TOKEN do not trigger downstream workflows. Use a GitHub App token so the PR's own CI actually runs. Idempotency: deterministic branch names + gh pr list --head guard. Empty-diff guard with git diff --quiet. --allowedTools prefix footgun: Bash(git push *) with the trailing space, not Bash(git push*). The pull_request_target footgun only bites on untrusted fork code; internal nightly auto-PR is on the safe side.
June 17 · length unknown
Blast-Radius Engineering in Claude Code: Bounding What an Unattended Run Can Touch with IAM, OIDC, and Branch Protection
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: Claude-side: permission deny/ask/allow ordering, defaultMode dontAsk, the sandbox (failIfUnavailable, allowUnsandboxedCommands false, denyRead on credentials), PreToolUse hooks, --bare, --max-turns. Plus CVE-2026-25725 (SecurityWeek): why you bound damage outside the tool. AWS: least-privilege IAM, permissions boundaries, Access Analyzer policy generation, STS short-lived creds, SCPs, egress control, and Budgets actions. GitHub: scoped GITHUB_TOKEN, OIDC to AWS, branch protection, and environment reviewers. 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.
June 13 · length unknown
Autonomous-Run Safety in Claude Code: Sandboxing, Prompt-Injection Defense, and Audit Logs
Before you let Claude run unattended, you need three independent enforcement layers, because a prompt injection can change what the agent wants to do but never what the harness allows. This episode wires up the sandbox, the deny rules, and the audit trail into one locked-down headless run. Episode page & show notes Visit website Act II continues. This is the gate you put up before you let Claude Code run unattended. We build three independent enforcement layers, because they fail differently, and you need all three. The three pillars Sandboxing. The native Bash sandbox (docs) enforced by the OS: Seatbelt on macOS, bubblewrap + socat on Linux/WSL2 (sudo apt-get install bubblewrap socat). Default write is the working dir only; default read is the whole computer except denied dirs, which still includes ~/.aws/credentials and ~/.ssh unless you add denyRead. Network has no domains pre-allowed; the proxy does not inspect TLS, so broad domains like github.com are exfil paths. Key knobs: failIfUnavailable, allowUnsandboxedCommands, excludedCommands, CLAUDE_CODE_SUBPROCESS_ENV_SCRUB. Permissions & modes. Evaluation is deny then ask then allow, first match wins (Permissions). dontAsk is the unattended gem (fully non-interactive). --dangerously-skip-permissions is the anti-pattern: it replaces the prompt with nothing and offers no injection protection (Permission modes). Watch the gitignore-anchor footgun: /Users/alice/file is project-relative, not absolute. Prompt-injection defense. The lethal trifecta (private data + untrusted content + exfil channel). The patched Claude Code GitHub Action attack (Microsoft, oddguan, GMO Flatt): the Read tool bypassed the Bash sandbox and leaked /proc/self/environ. Fixed in claude-code-action v1.0.94. Plus auto mode, Security, and PreToolUse hooks. Audit logs. On-disk JSONL transcripts (.claude directory, unencrypted at rest), headless --output-format json with total_cost_usd (headless), and OpenTelemetry emitting claude_code.tool_decision and claude_code.tool_result out of the box. We close with one copyable locked-down headless workflow and the primary pitfall: the silent success of --dangerously-skip-permissions. Forward pointer: blast-radius engineering, next episode. News: Fable 5 and Mythos 5 pulled under a US export-control directive; Claude Code falls back to Opus 4.8 (switch with /model). Plus the v2.1.172–2.1.176 changelog hardening: enforceAvailableModels, nested sub-agents to 5 levels, and fixed permission-path matching.
June 10 · length unknown
Review-and-Fix Loops: The Cold Critic, the Fixer, and the Gate Before Full Autonomy
A code reviewer who wrote the code is the worst possible reviewer, so wire a cold-context critic against an Edit-capable fixer and an objective test gate. The one pitfall that breaks it: a fixer that games the gate by rewriting the tests instead of the bug. Episode page & show notes Visit website Act II of the agentic coding ladder: the trust rung. We build a review-and-fix loop where one agent critiques a diff while another repairs it, with a human still approving the result. This is wired entirely out of primitives from earlier episodes: subagents, skills, slash commands, hooks, the orchestrator pattern, headless mode, the Agent SDK, git worktrees, and the @claude GitHub Action. The core idea: a reviewer who wrote the code is the worst reviewer. You want a generator, then a critic in a fresh cold context, then a fixer, then an objective gate. Concepts and sources: Building Effective Agents (evaluator-optimizer, iteration caps) Reflexion and Self-Refine LLMs Cannot Self-Correct Reasoning Yet (intrinsic self-correction degrades without an external anchor) Multi-agent research system (verify high-stakes outputs with a separate pass) Building it in Claude Code today: Custom subagents in the agents folder under dot-claude Code Review and security-review ultrareview cloud fleet Headless mode with json-schema findings Agent SDK for the multi-round loop GitHub Actions for the hosted version The pitfall: the fixer reward-hacks the test gate, documented in ImpossibleBench and EvilGenie. Bound it with tool separation, immutable tests, and a PreToolUse hook. News: Claude Fable 5 lands in Claude Code via v2.1.170, plus v2.1.169 safe mode and the /cd command.
June 7 · length unknown
The Claude Code GitHub Action: @claude on Issues and PRs (Setup, Auth, Triggers, Pitfalls)
Install the claude-code-action via /install-github-app, then @-mention Claude on any issue or PR to get a committed branch and a ready-to-click PR link. The biggest gotcha: fork PRs on public repos can't read your ANTHROPIC_API_KEY, so the workflow silently does nothing unless you use pull_request_target on the base branch or Workload Identity Federation. Episode page & show notes Visit website This episode kicks off Act II: moving from power-user-at-the-keyboard toward supervised automation. A human still approves everything here. We set up the Claude Code GitHub Action so you can write @claude on an issue or pull request and have Claude read the repo, make changes, commit to a branch, and hand you a pre-filled PR link. Setup. Fastest path: run /install-github-app from inside the Claude Code CLI. It installs the Claude GitHub App, writes the workflow YAML under .github/workflows/, and creates the repo secrets. Needs repo admin, and works for direct Anthropic API users (cloud providers need manual config). Manual setup: install the App, add ANTHROPIC_API_KEY (or CLAUDE_CODE_OAUTH_TOKEN from claude setup-token for Pro/Max), and copy examples/claude.yml into your workflows folder. Triggers. Default phrase is @claude (word-boundary matched, so not @claude-bot). Default events: issue_comment, pull_request_review_comment, pull_request_review, and issues. Adding a prompt: input flips it into automation mode (runs without a mention). Permissions. Minimal block: contents: write, pull-requests: write, issues: write, id-token: write. Add actions: read for CI log access. Arbitrary Bash is off by default; enable specific commands via --allowedTools. Pitfalls. Fork PRs can't read secrets on public repos (prompt-injection defense). Fix with pull_request_target + checkout of the base branch, Workload Identity Federation, or a same-repo if: guard. Claude's own github-actions[bot] comments can't trigger another run (loop protection). Use a PAT/App token or workflow_run. Branch protection can reject direct pushes; allow claude[bot] to bypass or accept the create-branch-then-PR flow. Every mention is a full agent run on your key. Batch requests, cap with --max-turns. As of 2026-06-06, latest release is v1.0.140. v1.0 replaced v0.x's mode/direct_prompt/max_turns with prompt + claude_args. Builds on the prior Headless Claude Code episode: the Action is essentially headless Claude triggered by a GitHub event.
June 6 · length unknown
Headless Claude Code: drive claude -p and the Agent SDK from your scripts
Take Claude Code out of the terminal and into your scripts. Print mode and structured JSON, the Claude Agent SDK in TypeScript and Python, chaining sessions, and the permission-and-cost discipline that keeps an unattended run from deleting your repo or running up an API bill once the June 15 billing change lands. Episode page & show notes Visit website The Act II pivot from driving one Claude Code session by hand to calling it from a script: same agent, same loop, but you pre-decide what's allowed in code before the run ever starts. The tutorial. Print mode (claude -p) as a Unix citizen — piping stdin (and the 10MB cap), the --bare flag for deterministic CI runs, and structured output via --output-format json (the result, session_id, total_cost_usd, and subtype fields), stream-json with the init and api_retry events, and --json-schema for typed data instead of prose. The run-bounding flags — --max-turns, --max-budget-usd, --model/--fallback-model, --allowedTools/--permission-mode — and chaining turns with --resume/--session-id/--fork-session. Why a model refusal can't be caught from the exit code. Copyable patterns: a commit-message generator (and the space-before-* permission footgun), a stdin-fed typo linter that needs no Bash permission, and a locked-down CI run. Then the Claude Agent SDK (renamed from the Claude Code SDK in September 2025): query() and the options that mirror the CLI flags, custom in-process tools, the Python ClaudeSDKClient, hooks and subagents in code, and the can_use_tool permission callback. Full reference in the headless docs and the migration guide. The pitfalls. --dangerously-skip-permissions in an unattended run — how to recognize the silent-success failure, and the least-privilege allowlist that replaces it — and the June 15, 2026 billing change that moves Agent SDK and claude -p usage to a separate metered credit pool, plus how to watch total_cost_usd and bound it. News. Claude Code 2.1.166 (June 6): a fallbackModel setting (up to three), thinking-off controls, a "*" deny-all glob, and a cross-session permission-escalation fix; latest is 2.1.167 (changelog). 2.1.163 added additionalContext from Stop hooks, /plugin list, and version-pinning settings. And Claude Opus 4.1 is deprecated, retiring on the API August 5, 2026 (release notes). Earlier episodes referenced: CLAUDE.md and --resume, permissions and plan mode, custom slash commands and hooks, skills, subagents and the orchestrator pattern, MCP servers, cost and rate-limit engineering and evals, ultraplan/ultrareview, and parallel sessions with git worktrees.
June 4 · length unknown
The orchestrator pattern: promote one Claude Code session to dispatch waves of subagents
Stop hand-wiring parallel sessions and let one Claude become the dispatcher: it spins up waves of subagents that work in parallel and report back. Your first session that runs a team instead of a task, plus how to keep the roughly fifteen-times token bill from running away with you. Episode page & show notes Visit website The first rung of running a fleet instead of a session: promote one Claude Code session to a lead that dispatches waves of subagents, which work in parallel and report back. The tutorial. The orchestrator-worker pattern, drawn from Anthropic's multi-agent research system writeup (Opus lead plus Sonnet workers beat single-agent Opus by ~90%, at roughly 15x the tokens of a chat, with effort scaled to query complexity). How it maps onto Claude Code today: the Agent tool (renamed from Task in v2.1.63) spawns workers in their own context windows that return only a summary; the two-level limit (subagents can't spawn subagents, so "waves" are batches); foreground vs background workers and Ctrl+B. Writing a custom subagent in your project's agents folder, with the frontmatter that turns earlier episodes' cost levers into per-worker dials: model (Sonnet/Haiku workers under an Opus lead), maxTurns, effort, tools, skills, mcpServers, and isolation: worktree (the callback to last episode's worktrees). A worked fan-out migration: Explore to map files, partition by file ownership, complete delegation prompts, structured returns, and a synthesis-and-test stage, plus the packaged /batch skill (5-30 worktree subagents, a PR each). Where it scales next: agent teams and dynamic workflows. The pitfall: token blowup from over-orchestrating, with the blank-context worker, file collisions, and the lead losing the thread underneath it. How to recognize each on /usage and /context, and how to bound it. The rule: orchestrate for breadth and independence, stay single-agent for depth and coupling. News. Claude Code 2.1.162 (June 3): a waitingFor field in the agents JSON, Read deny rules now hide files from Glob/Grep, and Windows path-matching fixes (changelog). API changes June 2: no billing on zero-output refusals and a max_tokens cap on the advisor tool (release notes). Earlier episodes referenced: subagents, skills, CLAUDE.md, context windows, MCP servers, cost and rate-limit engineering, and parallel sessions with git worktrees.
June 3 · length unknown
Ultraplan and ultrareview: plan hard before Claude writes code, then review the diff cold
The two highest-leverage habits in a single Claude Code session: make it interview you and plan the whole change in writing before it touches a file, then make it tear the diff apart, cold, before anything gets committed. Both are free, and they cover each other's blind spots. Episode page & show notes Visit website The last big habit of driving one Claude Code session by hand well: front-load the thinking, then back-load the review. Two workflows, not commands, built from primitives you already have. Ultraplan. Plan mode as the substrate (shift-tab into the read-only state, the approval gate you can edit and send back), then the moves that turn it into a workflow: let Claude interview you to lock requirements before it guesses, write the plan to a file so it survives a context reset, and have it critique its own riskiest assumptions before you approve. Spend a large thinking budget where being wrong is costly, skip the ceremony on trivial changes, and remember thinking tokens bill as output (callback to the cost episode). Codify the ritual as a custom slash command with read-only allowed-tools. Sources: Claude Code common workflows, best practices, slash commands, and managing cost. Ultrareview. Review the diff, not your memory of watching it happen: git diff against main, automated gates first (typecheck, lint, tests, build), then human-and-model judgment on the logic and security bugs no check sees, the untenanted query and the secret in a log line. Use the built-in /security-review and the claude-code-security-review action (mind the prompt-injection caveat on fork PRs). Wire the mechanical floor into hooks so a failing typecheck can't be committed, and write the "before every commit" list into your CLAUDE.md. The pitfall: review theater. A session that wrote the code rubber-stamps its own work with vague praise and zero findings. Recognize it by the absence of specifics; fix it by reviewing the diff cold, in a cleared context or a subagent that never saw the code written, and by forcing a why-is-this-correct justification per change. That cold-diff reviewer is the doorway to the next episode's review-and-fix loop. News. Opus 4.8 fast mode reportedly got around 2.5x faster at roughly a third the old price (announcement); Claude Code 2.1.161 (June 2) now carries OpenTelemetry resource attributes through as labels and adds a done/total counter to the agents view (changelog); and a Strava MCP connector lands as the connector list keeps filling in. Earlier episodes referenced: permissions and plan mode, custom slash commands and hooks, skills, subagents, MCP servers, context windows and CLAUDE.md, cost and rate-limit engineering, and parallel sessions with git worktrees.
June 3 · length unknown
Parallel sessions and git worktrees: run several Claude Code agents without collisions
One repo, several Claudes, zero stepped-on edits. Learn to give each Claude Code session its own git worktree, an isolated working directory on its own branch, plus the port, dependency, and database collisions to dodge, and the rule for when fanning out actually beats one focused session. Episode page & show notes Visit website The first rung of Act two: stop driving one Claude Code session by hand and start running several in parallel without them colliding. The mechanism is git worktrees, multiple working directories backed by one repository, each on its own branch. The tutorial. What a git worktree actually is (shared history and object store, but isolated working files, HEAD, and index) and the one rule underneath everything: a branch can only be checked out in one worktree at a time, so each parallel session needs its own branch. The small command surface (git worktree add, list, remove, prune) and the nesting trap that pollutes your main checkout. Then Claude Code's built-in worktree support: the --worktree/-w flag, where it puts worktrees and how it names branches, basing each off origin/HEAD, the worktree.baseRef setting, branching straight off a PR number, the workspace-trust gotcha, the .worktreeinclude file for carrying your gitignored .env across, and isolation: worktree for the subagents we built back in Act one. The three collisions you'll actually hit, dependencies, ports (and why PORT in .env.local is silently ignored by the Next.js dev server), and the database, plus integration by pull request and partitioning work by file ownership. Finally, when NOT to fan out: the review bottleneck (roughly four to eight worktrees per developer before you're the constraint), coordination overhead, and the per-session token cost, drawing on Anthropic's best practices and cost guidance. News. Claude Code 2.1.160 and 2.1.161 (June 2): parallel tool calls are now fault-isolated, the Dynamic Workflows trigger keyword changed from "workflow" to "ultracode," and claude mcp stops printing your secrets, per the changelog. And the June 15 billing change: programmatic usage (the Agent SDK, claude -p, Claude Code GitHub Actions) moves to a separate metered credit pool billed at API rates, while interactive Claude Code stays unaffected, via The New Stack. Earlier episodes referenced: subagents, skills, CLAUDE.md, context windows, and cost and rate-limit engineering.
June 2 · length unknown
Cost and rate-limit engineering for Claude Code, plus evals so your prompts don't rot
The two skills most Claude Code power users skip: keeping token spend and rate limits predictable, and regression-testing the prompts, skills, and commands you depend on so they can't quietly get worse. What the cost command actually measures, the model and caching levers that really move the bill, reading your usage with ccusage and OpenTelemetry, and a small eval suite built on headless print mode and promptfoo. Episode page & show notes Visit website The last rung of doing everything by hand: spend less, and keep what you've built from quietly getting worse. Cost and rate-limit engineering. Why the /cost command is meaningful only on a pay-as-you-go API key and misleading on a subscription (use /status and /usage instead), and the gotcha where a stray ANTHROPIC_API_KEY bills you through the API while your Max plan sits unused. The two stacked limit windows (the five-hour rolling window and the seven-day weekly caps, including the separate cap on the top model), drawn from Anthropic's usage and limits docs and the Pro/Max plan guide. Current per-token pricing and the clean five-times pattern (output is 5x input; each model tier is ~5x cheaper than the one above), prompt caching at a 90% read discount and why a stable CLAUDE.md keeps the cache hot, and the batch path at 50% off. Reading your real usage with ccusage and exporting OpenTelemetry metrics to a dashboard. The levers that move the bill most: /model, /compact and /clear, subagents that return summaries, --max-turns, and the thinking-budget setting (thinking tokens bill as output). More in Manage costs effectively. Evaluating your own prompts, skills, and agents. Why your setup drifts (model updates, CLAUDE.md edits, accumulating instructions) and how regressions stay silent. Building a tiny eval suite with headless print mode: a fixtures folder, a pinned model, and code-based checks (does it compile, do tests pass, does it contain the required clause) before reaching for an LLM-as-judge rubric. promptfoo for assertions and judging, Anthropic's evals guidance that code-based grading wins when feasible, and four ways evals lie to you: tiny overfit sets, judging style over correctness, eval cost, and non-determinism. News up top: Opus 4.8 as the new Claude Code default with extra-high effort and Dynamic Workflows (docs), and today's 2.1.160 write-guard prompts (changelog). Earlier episodes referenced: permissions and plan mode, custom slash commands, skills, subagents, MCP servers, and context windows.

Showing 1–20 of 26 episodes