When /config Became Real Config in Claude Code

Lachlan Reed

[warmly] Welcome to the show. James, I wanna start with a tiny file that suddenly got a lot more powerful: ~/.claude/settings.json. In version 2.1.119, a bunch of stuff people changed through /config stopped being floaty session fluff and started writing into that file for real. So theme, editor mode, verbose output -- the things you’d poke in the moment -- now survive a restart instead of vanishing like a snag off the barbie.

James Turner

[curious] Wait -- 2.1.119 is the line in the sand? Because that matters. If I flipped verbose output before 2.1.119, quit, came back, and it was gone... that wasn’t me imagining it. That setting literally lived as session state?

Lachlan Reed

Exactly. Before 2.1.119, you could change something in /config and think, sweet, sorted -- and then relaunch and it’d disappear. Or, worse, you’d get surprised because some other scope overrode it later. Now the mental model’s cleaner: if it’s a real setting changed there, it gets written to ~/.claude/settings.json at the user level.

James Turner

[skeptical] And that phrase you used -- “some other scope” -- is the whole game, right? Because the surprise is not just persistence. It’s precedence. Once you write to ~/.claude/settings.json, you’re in a stack. User global at ~/.claude/settings.json, project at .claude/settings.json, and then managed policy above both?

Lachlan Reed

[matter-of-fact] Yep. That’s the upgrade in thinking. Claude Code is now much more obviously living in the same multi-scope world as CLAUDE.md and programmatic config. So instead of /config feeling like a side panel with vibes, it’s part of a proper hierarchy: your global defaults, the repo’s defaults, then policy if your org manages things.

James Turner

[responds quickly] I’m grabbing onto “CLAUDE.md” there, because that’s the analogy that makes it click for me. People already understand that one file can set expectations globally and another can narrow them in a project. So now /config isn’t outside the system anymore -- it’s feeding one layer of it.

Lachlan Reed

That’s it. And I think this changes how developers feel the tool, not just how it works. If your theme sticks, okay, nice. If your editor mode sticks, also nice. But verbose output is the spicy one. Because that sounds cosmetic until you’ve built a workflow around seeing more detail. Then it’s not really a preference anymore, it’s like... your dashboard layout in a race car. Move one mirror and suddenly you’re driving weird.

James Turner

[questioning tone] Yeah, was verbose mode ever “just UI”? I don’t think so. If somebody depends on verbose output to understand tool behavior or trace what happened, losing it on relaunch changes how they work. That’s not dark mode versus light mode. That’s operational.

Lachlan Reed

[chuckles] Right -- one’s wallpaper, the other’s instrument panel. And before this change, I can easily picture someone toggling verbose on every morning like some daft little ritual, not realizing the product basically treated it as temporary. I’ve done versions of that in dev tools myself. You think, “Why do I keep redoing this?” Then three weeks later you realize the setting was never saved anywhere. Makes you feel like you’ve been kicking your own trail bike wondering why it won’t start.

James Turner

[laughs] The “every morning ritual” is real. But there’s another tension here: persistence sounds good until the wrong thing persists. If someone was using /config as an in-the-moment override, 2.1.119 means that choice now sticks in ~/.claude/settings.json. So after upgrading, you can inherit your own old impulse decisions.

Lachlan Reed

[reflective] Yeah... and that’s where this gets interesting. The old pain was “why didn’t it stick?” The new pain, for a few people, might be “hang on, why IS it still like this?” But I’d still take the new problem. At least now it behaves like real configuration. Real config can be inspected, reasoned about, checked against project settings. Slippery session state is just ghosts.

James Turner

[softly] And ghosts are brutal in tooling. Because when something disappears between sessions, you blame yourself. When it’s in ~/.claude/settings.json and the project has .claude/settings.json and policy sits on top, you can actually debug it. You can ask: which layer won?

Lachlan Reed

[short pause] That phrase -- “which layer won?” -- is the whole listener takeaway for me. After 2.1.119, /config isn’t just a momentary knob-twiddle. It writes into the config stack. And once you understand that, a lot of weirdness stops being weird.

James Turner

So let’s do the team angle, because this is where the change gets properly useful. If a repo has .claude/settings.json, a team can set project defaults there and everybody who contributes inherits them automatically. No more “hey, did you remember to toggle the thing in /config?” for every new dev, contractor, or sleepy teammate on a Monday.

Lachlan Reed

[excited] That’s such a clean win. .claude/settings.json becomes the campfire rules for the repo. You rock up, open the project, and the defaults are just there. Nobody’s passing around screenshots of menus or a dodgy setup doc from eight months ago.

James Turner

But -- and this is the enterprise catch -- managed policy still wins. That’s important. If a company policy pins a model or disables a tool, your local /config change can be ignored. Same if the project setting is more specific than your user default. So persistence does not mean absolute control.

Lachlan Reed

[skeptical] Which is exactly the kind of thing that trips people up. They go, “But I changed it locally!” Yeah, mate, but managed policy is sitting on top like the final boss. If policy says no tool, or the project pins the model, your shiny local preference in ~/.claude/settings.json doesn’t get the last word.

James Turner

[sharp] “Pinned a model” is the token I’d underline. Because that’s the silent override problem in one phrase. A developer can think /config is broken when it’s actually obeying a higher scope. The software is being consistent; the human mental model is what lags.

Lachlan Reed

And honestly, 2.1.119 helps there too, because at least now the local part is visible and persistent. You can audit ~/.claude/settings.json after upgrading. That’s not just housekeeping -- it matters because some people were using /config as a workaround precisely because settings used to reset between sessions. Those workaround toggles may now hang around.

James Turner

[matter-of-fact] Yeah, “audit after upgrading” is the practical advice. Open ~/.claude/settings.json and see what’s in there. If you were repeatedly setting something because it never persisted before, now it may persist. And that can be good or bad depending on whether that setting was a true preference or just a temporary patch.

Lachlan Reed

It’s a bit like finding sticky notes you forgot you left under the desk. They were never the system... until suddenly they are. [laughs] And for teams, this is healthier. Put the durable team defaults in .claude/settings.json. Leave personal stuff in ~/.claude/settings.json. Expect policy to overrule both if you’re in an enterprise setup. Nice and orderly. For once, the ducks are roughly in a row.

James Turner

Two quick additions here are worth calling out because they fit the same theme: less hidden friction. One is prUrlTemplate. That can redirect the footer PR badge to a custom review system -- GitHub Enterprise, Gerrit, or some internal tool. So if your org doesn’t live on plain github.com, the link can point where your reviews actually happen.

Lachlan Reed

[curious] And that’s not just cosmetic either. “Footer PR badge” sounds small, but if it lands in GitHub Enterprise or Gerrit instead of the wrong place, that’s one less paper cut every single review. Tiny things done fifty times a week become the whole weather.

James Turner

Exactly. And the other one: --from-pr now supports more than github.com PR URLs. It works with GitLab merge requests, Bitbucket pull requests, and GitHub Enterprise PR URLs too. That’s a pretty concrete widening of the on-ramp.

Lachlan Reed

[responds quickly] GitLab merge requests, Bitbucket pull requests, GitHub Enterprise PR URLs -- that trio tells you who this is for. Not just the default public GitHub crowd. Teams with oddball, legacy, or locked-down setups get to stop pretending they’re second-class citizens.

James Turner

[reflective] And that might be the bigger story underneath all of this. 2.1.119 makes /config less magical and more legible. Settings live in files. Files have scopes. Scopes have precedence. Links point to the review systems people actually use. It’s less “trust the UI” and more “understand the stack.”

Lachlan Reed

[softly] Yeah. And once a tool crosses that line -- from temporary convenience into explicit, layered config -- teams start depending on it differently. Not like a toy menu. Like infrastructure. Anyway, check your ~/.claude/settings.json before it checks you. [chuckles] Catch you next time.

James Turner

See you.