Welcome to the show!
I'm Lachlan Reed with James Turner,
and mate, I wanna start with a tiny terminal annoyance that used to drive
me properly up the wall: you're in a busy session,
tool output starts pouring in,
and the whole screen does this little partial redraw shimmy.
In tmux panes, over SSH, especially when a command runs long,
Claude Code used to sort of flicker and jitter like the terminal was
breathing through a paper straw. That phrase -- "partial redraws"
-- is exactly it.
Not a crash, not even a bug you can screenshot cleanly.
Just constant visual churn.
And in 2.
1.110, `/tui fullscreen` is the first version that fixes that
without making you restart the session,
right?Yeah, that's the bit.
Before, going fullscreen could feel like opening a whole separate world.
In 2.
1.110, `/tui fullscreen` switches the CURRENT session into the full
TUI renderer.
Same conversation, same context,
no fresh session, no "righto, let's start over." It just...
settles down.
Wait -- "current session" is the important token there.
So if I'm mid-debug, halfway through a thread,
I don't lose the conversation history just to get the cleaner renderer?
Exactly.
You keep the thread intact, but the UI stops doing those ugly partial
refreshes.
And for people living in cramped tmux layouts or remote SSH boxes,
that matters more than it sounds.
The first time the terminal stops twitching during long tool output,
you notice it straight away. That's a serious UX threshold.
Because once the screen is stable,
your brain stops treating it like a chat toy.
It starts feeling closer to an editor -- not because of some giant new
capability, but because the display finally behaves like it respects your
attention.
Spot on.
It's one of those tiny changes that lands like a bigger one.
Like tightening a loose bolt on a trail bike -- same bike,
totally different ride.
And if you want it to stick, there's a concrete hook now: the `tui` setting
persists the mode.
Drop `{ "tui": "fullscreen" }` into `settings.
json`,
and it'll come back that way across launches.So if
somebody tests `/tui fullscreen` once,
closes Claude, reopens it, and says,
"Huh, didn't stick" -- the missing piece is that JSON line: `{ "tui":
"fullscreen" }`.Yep.
Session switch first, config second.
That's the whole trick.
And I know this sounds almost too small to gush about,
but once the flicker goes away,
Claude Code feels less like a window that's trying to keep up and more
like a proper working surface.
Which, honestly, is a bigger deal than any splashy feature name.
The other cleanup in 2.
1.110 is pure interface hygiene: `/focus` is now
the dedicated command to hide tool calls and show only Claude's final
answer, while Ctrl+O just toggles between normal and verbose transcript.
That split sounds tiny, but it's actually a separation of concerns.
And by "separation of concerns," you mean two things that used to be bundled
but were doing different jobs, yeah?
Exactly.
Focus mode is for READING.
You want the clean final explanation,
no tool chatter, no command-by-command trail.
Verbose transcript is for INSPECTION.
Something looks off, you hit Ctrl+O,
and now you can see what Claude did step by step.
Those are not the same mental mode.That's so developer-brain.
We jam two buttons into one, live with it for ages,
then later go, "Ohhh...
maybe that was a dog's breakfast."
It is.
But here's the concrete workflow: say Claude helps with a long refactor.
Most of the time, you don't wanna read every tool call.
You want the final explanation -- what changed,
why, what to verify.
`/focus` gives you that cleaner view.
But if a file looks weird or a rename seems suspicious,
Ctrl+O is the panic flashlight.
Now you inspect the full trail.
So let me try to explain it back -- slightly
wrong on purpose.
`/focus` is kind of like "hide the kitchen," and Ctrl+O is "show me the
whole recipe card"?
Or is that too cute?
No, that's actually good.
"Hide the kitchen" for `/focus` is dead on.
And Ctrl+O is: show me every ingredient,
every step, every mess on the counter.
The old behavior bundled "I want less noise" with "I want more detail,"
which is...
well, backwards if you say it out loud.That's why this kind
of split feels obvious only AFTER you've suffered through the old setup.
Some devs will shrug -- "eh, it's just a shortcut change." But if you've
ever bounced between wanting a readable answer and wanting the forensic
trail, you feel it in your bones.
Different jobs, different controls.
And importantly,
it's not dumbing anything down.
You still have visibility into tool use.
It's just no longer welded to the readability toggle.
That means less accidental mode switching,
less "wait, where did the transcript go," and a cleaner model in your
head.The feature I reckon a lot of folks will quietly love most
is `autoScrollEnabled: false`.
If Claude is running a long build or a chunky test suite,
the terminal no longer yanks you to the bottom on every fresh line.
You can keep your place, read older output,
and the session keeps going underneath you.
That `false` matters.
Because anyone who's watched tests stream by knows the pain: you scroll
up to the first failure, one new line lands,
and boom -- you're snapped back to the bottom.
It's like trying to read a book while someone keeps flicking the page
forward.Exactly.
And paired with the steadier fullscreen TUI,
it makes long-running output way less feral.
There's also a neat `/config` option now: when you launch an external
editor with Ctrl+G, Claude's last response can be injected as commented
context right into the buffer. Right,
and the specificity there is nice: vim,
nvim, or VS Code can open with the relevant suggestion already sitting
in the file as a comment block.
So instead of alt-tabbing back to remember what Claude said,
the guidance is literally in the editing surface.
That's a lovely handoff.
Very practical.
But -- and here's the sharp edge -- Bash now enforces its documented
maximum timeout.
It doesn't just accept absurdly large values anymore.
So if you've got prompts, scripts,
or headless workflows that relied on giant or basically "infinite" timeouts,
those may suddenly throw errors. "Documented maximum timeout"
is the phrase people need to hear twice.
Because if somebody set a cartoonishly high number months ago and forgot
about it, 2.
1.110 can expose that assumption fast.
This is one of those reliability fixes that feels like a regression only
if you were leaning on undefined behavior.
Yeah,
and there was another hardening pass too: "Open in editor" no longer
blindly shell-interpolates filenames.
That's important.
If Claude suggests a file to open,
the filename isn't just stuffed into a shell command raw anymore,
which closes off a command-injection path.That one is
huge, even if it sounds boring.
Convenience features become attack surfaces FAST.
A filename looks harmless right up until somebody realizes it can smuggle
shell syntax.
So this release is doing two things at once: making the terminal feel
smoother for humans, and less trusting in places where trust is dangerous.
Before
teams go all in, there are a few things worth auditing.
First: `/tui fullscreen` is session-level unless you persist it.
So if one developer tries it in a shell,
loves it, then opens a new session and thinks it disappeared -- that's
not a failed feature.
That's just unsaved config.Which comes back to that
exact line in `settings.
json`: `{ "tui": "fullscreen" }`.
Without that, you're only changing the current session.
I can absolutely see a whole team trying it once and going,
"Nah, didn't work," when really they just didn't save the mode.
Second,
terminal compatibility still matters.
Older macOS Terminal.
app had garbled startup rendering in earlier versions
because synchronized output wasn't handled well.
2.
1.110 addresses that, which is good,
but if fullscreen still looks off,
it's smart to test in a modern terminal emulator before blaming Claude
itself.
That is such a classic terminal rabbit hole.
You think the app is busted, then it turns out your emulator is the one
dropping the ball.
Not always, but enough that it's worth checking.
Especially if the rendering weirdness shows up right at startup.
And third:
audit your Bash timeout assumptions now.
Not later, now.
If you've got automated scripts,
SDK sessions, or long-running Bash tasks using values way above the documented
ceiling, this release can surface that immediately.I like
that framing because it's not just "here's a shiny TUI update." It's also,
"mate, check your plumbing." Stable fullscreen,
cleaner focus modes, auto-scroll control,
safer editor handoffs -- all good stuff.
But the minute a tool gets more capable and more integrated,
the rough edges matter more too. Yeah.
And maybe that's the bigger question hanging over all of this.
Once Claude Code has a stable fullscreen TUI,
smarter reading modes, and editor handoffs that feel intentional instead
of hacked together...
does the terminal stop feeling like a prompt you visit,
and start feeling like an actual working environment you inhabit?
That's a good one to leave rattling around in the toolbox.
Thanks for listening, and we'll catch you next time.