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.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?
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.
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?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.[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.
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.
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.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.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.
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.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?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.
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.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.
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.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."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.
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.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.
It's a bit like finding sticky notes
you forgot you left under the desk.
They were never the system...
until suddenly they are.
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.
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.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.
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.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.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."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.
Catch you next time.
See you.