Claude Code Gets a Clean Purge and Safer OAuth Login

Lachlan Reed

[warmly] Welcome to the show. James, I wanna start with a very specific kind of misery: you refactor a project, hop branches, maybe nuke a feature folder, come back to Claude Code... and it feels HAUNTED. It's still remembering the old transcript, the old task trail, file history from before the branch swap, maybe even a config entry tied to a project shape that doesn't exist anymore. And until now, the fix was the least glamorous thing on Earth -- rummaging through cache directories by hand like you're cleaning out a shed full of mystery bolts.

James Turner

[laughs] The phrase "haunted by stale transcripts" is painfully accurate. And the part I always hate is "by hand." Not conceptually hard, just... fragile. You're poking around local state, half sure you're deleting the right thing, half sure you're about to remove the one file that's secretly keeping the whole tool upright.

Lachlan Reed

Exactly. So the clean fix now is a real command: `claude project purge [path]`. And what's nice is it's not vague housekeeping. It removes four concrete buckets for that project: transcripts, tasks, file history, and the project's config entry. That's the lot. Proper reset. Fresh paddock.

James Turner

[questioning tone] Wait -- the config entry too? So not just the conversational memory, not just tasks, but the actual project registration Claude Code has for that path?

Lachlan Reed

Yep, the config entry too. Which matters, because stale behavior often isn't just "the bot remembers a chat." It's the whole local state bundle. If the project identity itself is hanging around with old assumptions, you can get that uncanny valley where the tool is technically working, but every suggestion is leaning on the wrong context.

James Turner

And that "wrong context" bug can waste an hour easy. I had one of these -- not with this exact command, obviously, before it existed -- but same class of problem. I switched branches, one branch had a different file layout, and the tool kept acting like a deleted file still mattered. It wasn't crashing. That's the evil part. It was confidently helping in the WRONG universe. I spent, I don't know, maybe 50 minutes debugging my repo before realizing the assistant was the thing carrying stale state.

Lachlan Reed

[chuckles] That's such a developer trap. When a tool is wrong in a loud way, you fix it fast. When it's wrong in a plausible way, mate, that's where your afternoon goes to die. Like a trail bike with one slightly dodgy bolt -- it'll run just well enough to get you stranded somewhere inconvenient.

James Turner

The phrase for me is "plausibly incorrect." Those are the expensive bugs. So talk me through the safety rails here, because "purge" is one of those words that makes me sit up straight.

Lachlan Reed

[matter-of-fact] Fair. There are four knobs people should remember. `--dry-run` previews what would be deleted before anything actually goes. That's the "don't be a hero" flag. Then `-y` or `--yes` skips the confirmation prompt if you're automating or you already know what you're doing. `-i` or `--interactive` lets you selectively delete, which is lovely if you don't want the full scorched-earth treatment. And then there's `--all`, which purges EVERY project Claude Code knows about.

James Turner

[skeptical] `--all` is the one that makes me inhale through my teeth. Every project Claude Code knows about? That's not "clean this room," that's "empty the house."

Lachlan Reed

[laughs] Yeah, `--all` is not for a casual Friday click-around. That's why `--dry-run` matters so much. If you're about to wipe every remembered project -- transcripts, tasks, file history, config entries, the whole shebang -- you really want a preview first.

James Turner

And `-i/--interactive` is the opposite vibe. Same purge tool, but selective. That's actually smart, because stale state isn't always global. Sometimes one repo is cursed and the rest are fine.

Lachlan Reed

Right. One repo's cactus, the others are sweet. And honestly, that's why I like this update. It turns Claude state into something more disposable. If a project gets weird, you don't treat the weirdness like sacred archaeology. You purge it, verify with `--dry-run` if you're nervous, and move on.

James Turner

[reflective] That's bigger than it sounds. Developer tools get better the moment you're not afraid of their memory. If state can be reset cleanly, you experiment more. If state feels sticky and mysterious, you get conservative. You start working around the tool instead of with it.

James Turner

[urgent] Okay, now for the one with teeth. `--dangerously-skip-permissions` got more dangerous in a very real, behavioral way. Before, even with that flag enabled, some protected paths could still trigger permission prompts. Now it bypasses prompts for writes to `.claude/`, `.git/`, `.vscode/`, and shell config files. That's a major change, because those are exactly the directories and files that can alter how your environment behaves.

Lachlan Reed

[questioning tone] So let me explain it back and you tell me if I've got mud on the tyres: previously, "dangerously skip" still had a bit of hidden adult supervision for `.git/`, `.vscode/`, shell config, and `.claude/`. Now that supervision is gone for writes to those paths?

James Turner

Almost -- yeah, that's the crux. Those paths used to still prompt even with the flag on. Now the prompts are bypassed there too. So if you were mentally treating the old behavior as "dangerous, but with a few brake pedals left," that's outdated.

Lachlan Reed

`.git/` is the one that lands for me. If you're writing inside `.git/` without a prompt, you're not just editing app code -- you're potentially changing repo behavior. `.vscode/` means editor settings. Shell config files mean environment startup. That's not a paper cut. That's "the whole workshop smells like petrol" territory.

James Turner

Exactly. And for CI/CD, this is where people need to audit immediately. The practical effect is that the flag is now truly non-interactive for those protected paths. So if an automation flow was quietly relying on those prompts as an accidental guard rail, that guard rail is gone. The replacement should be explicit path-based allow rules and deny rules, not vibes, not "well it used to stop and ask."

Lachlan Reed

[skeptical] That's such a good distinction: if your safety model depended on an interruption, you didn't really have a safety model. You had a speed bump. And speed bumps are useless if someone just paved over them.

James Turner

[laughs] Yes. Perfectly put. But there is one exception worth keeping in the listener's head: catastrophic removal commands still prompt regardless. So "dangerously skip" is broader now, but it's not a total free-for-all.

Lachlan Reed

Catastrophic removal commands still prompt -- that's the sentence I wanted. Because otherwise the update sounds like the doors have been taken off the hinges completely. They haven't. It's looser, not lawless.

James Turner

Right. Broader bypass, not absolute bypass. And then there's a totally different fix that I think a lot of developers are gonna FEEL immediately: `claude auth login` can now accept the OAuth code pasted directly into the terminal when localhost callbacks fail.

Lachlan Reed

[excited] That is huge for WSL2. And SSH sessions. And Docker or devcontainer setups. Because the annoying bit there is never the concept of OAuth -- it's the callback. The browser opens, localhost is meant to receive the handoff, and in those environments the whole thing can go a bit pear-shaped.

James Turner

Exactly. "Paste the code into the terminal" is not glamorous, but it solves a very specific friction point. WSL2 users in particular are gonna recognize that immediately. Same for remote shells and containers where localhost callback behavior gets weird or broken.

Lachlan Reed

It's one of those fixes that sounds tiny in a changelog and massive in real life. Like, no one's making a movie trailer voice about "manual OAuth code entry," but when you're stuck in a devcontainer and auth won't complete, that one path feels like fresh water in the desert. Bit dramatic, but you know what I mean.

James Turner

[chuckles] No, that's right. And I want to end on the quietest but maybe most important fix: `allowManagedDomainsOnly`. There was an enterprise bug where a higher-priority managed-settings source could previously let blocked requests through if it lacked a sandbox block. That's subtle. It's the kind of policy-enforcement failure nobody notices until the day policy enforcement actually matters.

Lachlan Reed

[softly] That's the spooky category of bug, isn't it? Not "the app exploded," but "the rule you thought was protecting you wasn't actually winning in all cases." Higher-priority settings sound safe by definition, and yet if that source lacked a sandbox block, blocked requests could slip through. That's... not flashy, but it's serious.

James Turner

Yeah. It's a reminder that security bugs are often about precedence, not drama. Which setting wins. Which source overrides which. Whether a missing sandbox block creates a hole you didn't know existed. Nobody brags about that fix on social media. But when enterprise policy is the thing separating "allowed" from "absolutely not," quiet correctness matters more than shiny features.

Lachlan Reed

[reflective] That's the throughline for me: one update makes local state disposable, another makes automation more honest about risk, another removes auth pain in weird environments, and the last one tightens policy where it counts. Different fixes, same lesson -- the dangerous stuff in tooling is usually the invisible stuff. Catch you next time.

James Turner

See ya.