`main` dropped the agent-turn cuts from the reader's `flush_batch!` and
added `foreground_command` to `replay_state`; both are kept, with the
per-pty `repair_cursor` flag replacing `REPAIR_PARKED_CURSOR` in the
simplified cut loop and the mode restore ahead of the new signature.
Claude-Session: https://claude.ai/code/session_01JRqYZ9E153WpSHGS2AW3BM
The memo made the connection's `proved_server` slot both the note and the
install gate, and `ensure_remote_server` holds it across the probe for a
reason the two operations that change the server share: a pane arriving
mid-install must wait rather than upload over the file the winner is
renaming into place. `restart_remote_daemon` and `replace_remote_server`
only cleared the note and then let go, so a pane opening during a replace
still probed against a half-moved binary — and now *kept* that answer for
the life of the connection, where before the memo it cost that one pane
and no other. The sharp end is the mismatch the note re-files on every
hit: probe the machine while the replace has uploaded but not yet
restarted, and the outgoing daemon is filed as a mismatch that every
later pane on that connection hears about, long after the replace the
user asked for fixed it. Both now run inside the guard, the note dropped
first, the way `wsl::replace_wsl_server` holds its distro's install lock.
That makes the hold as long as a replace, so the router's forget on a
silently closed link moves off the thread polling the route: it took the
same non-reentrant lock, and waiting there kept the client's half of a
link that was already gone open for as long as whatever held it.
Claude-Session: https://claude.ai/code/session_01JRqYZ9E153WpSHGS2AW3BM
`replay_state` sends the mode fold ahead of the ring so the replayed
frames land in the buffer they were drawn for, and it sent every mode
that was on — including the ones the ring itself still switches on.
`?1049h` is a no-op in the emulator once the mode is already set, so the
ring's own copy then stopped clearing the alternate screen: everything
the ring holds *ahead* of that sequence, which is the shell scrollback
the user had behind the program, was painted into the alternate buffer
instead. That buffer keeps no history, so those lines were thrown away,
and the primary buffer the program's exit returns the client to was left
empty. Reconnecting a minute after opening `vim` is the ordinary case,
and it lost the prompt the user left behind.
Only the modes a replay of the ring cannot speak for go ahead of it now,
and they are read from a fold over the bytes the ring actually still
holds — so a sequence the front cut in half counts as lost, exactly as
it will for the emulator that reads the same bytes.
Claude-Session: https://claude.ai/code/session_01JRqYZ9E153WpSHGS2AW3BM
Three things the new probe verdict still got wrong.
`GetExtendedTcpTable` refusing came back as an empty buffer, which read
exactly like a family with no listeners, so the Windows branch answered
`Ok` about ports it had never looked for — the silence #731 is about, on
the platform the panel was written on. `tcp_table` says `None` now, and
only "neither family answered" is `Unavailable`: a machine with IPv6 off
keeps its `Ok` and its IPv4 ports.
The `Unavailable` warning was written on every `QueryProcs`, and the
Info panel sends one every two seconds — thirty identical lines a minute
into a log that truncates itself at 4 MiB, which costs a reporter the
rest of the session they turned logging on to capture. Same reason, once
a minute.
And `Restricted` on Linux took `/proc/<pid>`'s owner for the process's
uid. The kernel hands that directory to root whenever it clears a
process's dumpable attribute, which is what executing a set-user-ID
binary or one carrying file capabilities does, so a plain `ping` in a
pane had the panel apologising for sockets it can read perfectly well —
the opposite mistake, and just as wrong. The `Uid:` line of
`/proc/<pid>/status` settles the few rows that look foreign and are in a
pane's tree, so an ordinary pane pays nothing for it.
Claude-Session: https://claude.ai/code/session_01JRqYZ9E153WpSHGS2AW3BM
The shared table sent F3 as `SS3 R` / `CSI 1;<mods>R` to a client that had
negotiated the kitty keyboard protocol. Kitty's first version allowed that
letter form and then removed it: `CSI 1;2R` is also a Cursor Position Report
for row 1, column 2, so a client cannot tell Shift+F3 from an answer to its
own DSR. The protocol's table gives F3 as `CSI 13~` alone -- the VT220 `kf3`
-- and alacritty special-cases exactly this. Only the kitty path moves;
everyone reading terminfo still gets the `kf3=\EOR` we advertise.
F13..F24 were left unencodable on both paths for a terminfo reason that holds
only on the legacy one: `kf13` onwards are already the modified F1..F8, so
there is nothing to send. Kitty has no such clash -- it names them in the
private use area, `CSI 57376 u` for F13 -- so a client that asked for the
protocol now gets them, and the legacy path still sends nothing.
Claude-Session: https://claude.ai/code/session_01JRqYZ9E153WpSHGS2AW3BM
`rustfmt` is a required check and was red on three hunks of this branch:
`owner_of`'s signature, the `--cwd` argv in `tab_new`'s adopt test, and the
two `tab_create` calls in `the_document_being_replaced_is_kept_beside_it`.
`keep_a_generation` also read the whole document before asking whether it
was going to keep anything. It runs on every persist — pane facts alone
flush every couple of seconds — and answers "too soon" on almost all of
them, so that was a full read of `machine.json` per write to produce one
copy every five minutes. The spacing check moves ahead of the read; the
`NotFound` arm still covers the machine that has never written a tree.
And a line continuation was missing from an assertion message in
`a_typed_name_waits_for_the_create_rather_than_racing_it`, so the failure
would have printed eighteen spaces mid-sentence.
Claude-Session: https://claude.ai/code/session_01JRqYZ9E153WpSHGS2AW3BM
`skills/tty7/references/commands.md` is the agent-facing twin of
`docs/cli/reference.mdx` — the two have moved together in every commit that
changed a CLI surface — and it was left behind by this branch. It still
announced `capture [%PANE] [--plain] [--scrollback]`, "two independent
choices", and `JSON: {"pane","text"}`, so an agent reading the skill was being
told a shape the binary no longer prints and a flag list that no longer holds.
Says the same three things the reference now says: the resize boundary the
default form is bounded by and to ask for `--scrollback` under the GUI,
`--tail N` and why it trims last, and `bytes` as what tells an empty `text`
apart from a lost one.
Claude-Session: https://claude.ai/code/session_01JRqYZ9E153WpSHGS2AW3BM
CI found both new end-to-end cases red on Linux and macOS while green on
Windows. One was a bad assumption in the test; the other was the test
telling me the fix is narrower than the first commit claimed.
The real finding is the resize case. On Unix a resize raises SIGWINCH and
the shell repaints its prompt, so the segment the resize opens is *not*
empty — it holds the repaint. Dropping byte-less segments therefore
leaves the newest non-empty segment being a bare prompt, with the pane's
output still stranded in the segment sealed behind it: on CI the default
form came back as 174 bytes of prompt escapes and no marker. On Windows
nothing answers the resize, the segment stays empty, and the fix reaches
past it to the output — which is why the assertion passed there. It was
asserting an accident of the platform.
So the fix stands but is smaller than "a resize no longer costs you the
pane's output": it makes the zero-byte answer impossible, and that is
all. It cannot do more. Nothing in the byte stream distinguishes a prompt
repaint from output the pane meant, so no client-side rule can tell which
side of the boundary the answer is on. The boundary is the flaw — the
default form's unit is the last resize, an event in the window rather
than in the pane — and moving it means redefining what the default
returns (the last screenful of the ring, say), which would shrink what
every caller with a never-resized pane gets today. Left alone, and said
plainly instead: in `what_was_asked_for`'s doc comment, and in a warning
in the CLI reference telling anyone reading a pane under the GUI to ask
for `--scrollback`.
The test now asserts what the fix actually guarantees on every platform —
the default form answers with bytes rather than with the resize's
placeholder, and it is the end of what `--scrollback` returns, which is
what would catch a fix reaching for the wrong segment. The marker is
pinned against `--scrollback`, the form that promises to hold it.
The `--tail` failure was a race in the test, not in `--tail`: the whole
and the tail were separate calls and the pane advanced between them, so
the tail carried a prompt line the whole capture had not caught up to.
Both cases now read the whole answer on either side of the others and
require the two readings to match before comparing anything, which is
what makes the comparison a statement about the code rather than about
the moment. Both also read `--scrollback` now, so neither depends on
where a segment boundary happens to fall, and neither pins exact pane
content — the macOS runner prints a zsh banner into the pane.
Claude-Session: https://claude.ai/code/session_01UUyWQXzcBAoBzaSX8pc7nU
Every "how did the last command end?" query went through `| tail -n 5`,
which ships the whole grid down a pipe to throw most of it away — and on
Windows, where `capture` is just as useful, there is no `tail(1)` to pipe
to. `--tail N` keeps the last N lines of the answer instead.
It is a third independent choice beside `--scrollback` (how much of the
ring) and `--plain` (in what form), and it composes with both. The trim
runs last, after `--plain` has decided what a line is: a shell line the
pane wrapped over three rows is one line to the grid and three to a byte
counter, so `--plain --tail 1` hands back the whole of the last line
rather than its final row. The raw form counts the same way `tail` does,
splitting on the newline and leaving the CR of a CRLF attached to the
line it ended, so the bytes stay the pane's own. A trailing newline
terminates the last line rather than opening an empty one, which is the
difference between `--tail 1` answering the last line and answering
nothing.
`N` must be at least 1: a tail of zero lines would print an empty result
that reads exactly like the blank-pane ambiguity this issue is about, so
it is a usage error (exit 2) instead. `--json` reports the tail in `text`
but leaves `bytes` the size of the whole replay, so the pair still says
"this was trimmed" rather than "this came back short".
Left alone deliberately: the daemon still replays the entire ring on
every observe, so the saving here is the pipe, not the wire. Bounding
what crosses the wire means teaching `ClientMsg::Observe` a limit and
versioning the protocol for it, which is a much larger change than the
papercut warrants — and the default (newest-segment) form has always
received the whole ring and discarded most of it, so this adds no new
cost. The docs say so rather than implying otherwise.
Claude-Session: https://claude.ai/code/session_01UUyWQXzcBAoBzaSX8pc7nU
`tty7 capture %n` answered a live pane with zero bytes and exit 0, which
is byte-identical to a pane that had genuinely never printed. The report
guessed at the replay grid. It is not the grid — it is the segment the
grid was handed.
The daemon's replay ring splits on resize: `ReplayRing::resize` seals the
segment holding the output and pushes an empty one at the new geometry,
and `ReplayRing::replay` sends every segment it holds, empty tail
included. `RealBackend::capture` then kept "the newest segment" for the
default (non-`--scrollback`) form, and for any pane resized since it last
printed, the newest segment is that empty placeholder. A pane restored
from disk lands in the same state, because seeding the ring ends in a
resize too.
Measured end to end against a real daemon before the fix: a pane holding
954 bytes of scrollback answered `capture` and `capture --plain` with 0
bytes and exit 0 while `capture --scrollback` returned all 954. The fix
drops byte-less segments before choosing the newest one — they carry
nothing in either form, so `--scrollback` drops them too and both forms
describe the same bytes. The daemon still sends them: its trailing `Size`
is how an attaching client learns the pane's current geometry, and that
is not the CLI's to take away.
What this does not explain is the reporter's other half — that
`--scrollback` came back empty in the same episode. Filtering empty
segments cannot cause that, and neither could I reproduce it: 60 rounds
of `capture` against a pane spewing 4000 escape-laden lines produced no
empty result, and an 8 MiB ring (the cap) replayed whole in ~400 ms, well
inside the 300 ms per-frame settle window that was the other suspect. So
the silent-empty class is left distinguishable rather than declared
closed: `--json` now carries `bytes`, the size of the replay counted
before anything renders or trims it, and the one case where an empty
answer is not an empty replay — bytes in, no text out — says so in a line
on stderr. Zero bytes is a pane that printed nothing; bytes with no text
is a screen whose content did not survive the grid. Deliberately no retry
loop and no warning on a condition that has not been established.
Claude-Session: https://claude.ai/code/session_01UUyWQXzcBAoBzaSX8pc7nU
The switcher's scrim covers the whole window, the tile that opens it
included. Its mouse-down closed the switcher and then carried on down to
whatever sat beneath — for that tile, straight into `toggle_switcher`,
which reopened what had just closed. Clicking it a second time looked
like it did nothing.
Stop the press at the scrim. A click that dismisses is spent on the
dismissal and reaches nothing underneath it, so the tile toggles and no
control fires by accident on the way out.
Claude-Session: https://claude.ai/code/session_01XLMiHJR7RXvAGsR8S7jkHa
The tile's only hover state was a fill the palette derives one step off
the surface, which on the rail is barely a change at all — and the name,
the monogram and the chevron each pinned `muted_foreground`, so the
button's own hover ink never reached them. The one control at the top of
the column said nothing when the pointer landed on it.
Move the ink and the hover onto the row holding the three children and
let them inherit, the way a group header does: the text steps up to full
strength. The fill stays, it is simply no longer the whole signal.
Claude-Session: https://claude.ai/code/session_01XLMiHJR7RXvAGsR8S7jkHa
A restored pane came back with the killed program's mouse reporting still on,
so every pointer move over it was typed into the new shell's line as an SGR
report and the line grew for as long as the pointer stayed there.
The chain is short and each link is deliberate. A snapshot is a raw byte
stream, not a rendered grid, and `scrollback.rs` says so in its own module doc.
`ReplayRing::seeded` puts those bytes into the restored pane's ring verbatim,
and the client hands them straight to its parser at `DaemonMsg::Snapshot`. So
the dead program's `?1002h` is not a description of a screen, it is an
instruction, and it is executed a second time against a shell that never asked
for it. There is nothing after it to undo it: `DaemonPane::kill` is a hangup
with no grace period, so the program never emitted its own `?1002l`, and the
snapshot was photographed before the kill anyway. `restore_preamble` already
exists to keep exactly this kind of leftover away from the incoming shell — it
resets the alternate screen, the cursor, autowrap and the graphic rendition —
and it simply stopped short of the modes that make the terminal talk back.
It now also turns off mouse reporting and its encodings, focus reporting,
bracketed paste, application cursor keys and the kitty keyboard flags.
Unconditionally, which was the choice worth making. The alternative was to fold
the snapshot's bytes through a mode tracker and clear only what the fold says is
still on, which is what #828 does for the neighbouring re-attach path. That
precision is essential there and buys nothing here: there the pane is alive and
re-sending a mode it had turned off would be wrong, whereas here the target
state is a constant. The incoming shell is brand new, it has not written a byte
when the preamble is appended, and it asked for none of these modes, so there is
nothing to preserve and no mode whose value has to be discovered. The risk is
not symmetric either. Switching off a mode that is already off is a no-op in
every emulator, so the blunt version cannot fail; a fold that misparses one
sequence leaves the mode on and the bug exactly as it is today, silently. The
blunt version also needs nothing from #828, so this can merge in either order.
Left alone on purpose: `?1007` alternate scroll, which a default terminal has
on, so clearing it would walk away from the default rather than back to it;
`?2026` synchronised update, which the client's processor already closes out
when a replayed frame ends inside one; and `stale_mode_resets` in the client,
whose conditional shape is right for the live pane at a prompt that it serves.
Scrolling regions and origin mode are a different failure with no report behind
them and are not touched.
The test that locked in the short reset list now locks in the long one, and
asserts the `?1007` omission so it stays deliberate. A second test runs the
real chain — a snapshot ending inside a full-screen program, `ReplayRing::seeded`,
the preamble — and asserts that the ring a client would replay has `l` as its
last word on every reporting mode. Both fail on the previous preamble.
Claude-Session: https://claude.ai/code/session_01UUyWQXzcBAoBzaSX8pc7nU
The box opens holding the tab's label as rendered, so it is never empty,
and `commit_rename` fires on `Blur` as readily as on Enter. Opening the
box and clicking away therefore stored that label as the tab's name — one
the user never typed, and one that means something different from the
title it was copied from: a name stops following the pane, so the tab
froze on whatever it happened to say at that moment.
Read the box against what it was seeded with. `rename_outcome` answers in
three states rather than two, so the one that has to keep working keeps
working: an emptied box still clears the name, which is the only way to
give a tab back to its pane.
`status_dot` places itself with negative offsets so that it overhangs the
avatar's edge — that overhang is what makes it read as a badge sitting on
the disc rather than a notch bitten out of it. But it is added as a child
of the element carrying `rounded_full`, so everything past the circle is
clipped along the arc and the badge comes back as a crescent.
Give the wrapper the positioning and move the disc down a level. The
radius then only ever clips the disc's own fill and mark, and the dot
becomes a sibling drawn after it, which settles the paint order too.
No test: the change is structural — which element carries the radius —
and the tests here cover the pure decisions behind the avatar
(`needs_edge`, `agent_status_label`) rather than its element tree.
Outside a repo a sidebar row grew a second line for its working
directory, so a group of plain shells was a column of two-line rows
describing paths that mostly agree. The path now rides on the title's
own line: it takes what it needs up to half the line and the title
keeps the rest, the same split a group header makes with the branch
beside its heading. A row keeps its second line only for a branch.
Claude-Session: https://claude.ai/code/session_01VuYUPiDEhQX6aQ4WQZbEGn
A group whose rows share a branch already prints it once on the header
instead of once per row, but the rule asked for at least two rows. A
one-tab group was left with a bare heading over a two-line row, a shape
no other group in the column has, and the branch down there described
the same repo the heading above it already named.
Claude-Session: https://claude.ai/code/session_01E4EPKzHg1fm9HMmHkUYpER
F1 through F12 produced no bytes at all. `functional_key` in
`src/terminal/input.rs` is the one place a named key becomes an escape
sequence, and it knew the cursor and editing keys and nothing else; the
`key_char` fallback below it cannot help, because a function key arrives
with no character, and `text_key_code` gives up the moment a key name is
longer than one character. Both encoders funnel through that function,
so the kitty path was equally blank. This was never a Windows or a
PowerShell problem — it was every platform, every shell — but it shows
up first on Windows because PSReadLine keeps CharacterSearch on F3,
HistorySearch on F8 and ClearHistory on Alt+F7, so the missing keys are
part of the shell's ordinary editing surface rather than something
exotic.
The table is `xterm-256color`'s, since that is what we advertise in
`$TERM`: `kf1`..`kf4` are the SS3 letters, `kf5`..`kf12` the numbered
tilde forms whose numbering starts at 15 and skips both 16 and 22.
Modified, they take the same `CSI 1;<mods>` and `CSI <n>;<mods>` shapes
the cursor keys already use, which reproduces `kf13` onwards exactly —
`kf13` is Shift+F1, `kf25` is Ctrl+F1. DECCKM is deliberately not
consulted: unlike `kcuu1`, `kf1` is SS3 under both `smkx` and `rmkx`.
It stops at F12 on purpose. In the entry we advertise there is no
capability left for a thirteenth key — `kf13` and up are already the
modified forms of F1..F8 — so sending the VT220 `\E[25~` for a physical
F13 would hand ncurses a sequence its own table reads back as Shift+F1.
Silence is the more honest answer, and F13+ keys are close to
nonexistent on the keyboards this bug was filed from.
Encoding alone would not have reached the shell, because two things
upstream were eating the keys first. The inline prompt editor had no arm
for a named key it does not bind, so F8 fell out of the bottom of
`handle_editor_key` and died on a `cx.notify()`; it now takes the same
route an unknown Ctrl chord takes, handing the line to the shell before
sending the key, which is what PSReadLine's history and character
searches need in order to act on it. And Find Next / Previous sit on F3
and Shift+F3 off macOS, where gpui matches the binding before the pane's
key handler ever runs; with no find bar open there is no match to step
to, so those listeners now give the keystroke back the way `EditorSave`
gives back Ctrl+S.
F11 keeps fullscreen. It is the chord Windows Terminal, GNOME Terminal
and konsole all use, no shell binds it, the modified forms still reach
the PTY, and it is one line of config away from being retired — but it
is now a stated choice with a test standing on it rather than an
accident. The reporter's second clause is explained rather than fixed:
`prompt_editor` is a real gate, and turning it off could not help while
the bytes did not exist, which is exactly what they saw.
Claude-Session: https://claude.ai/code/session_01UUyWQXzcBAoBzaSX8pc7nU
A header that carried its group's shared branch handed the overflow to
the name and the branch by flex shrink, which splits it in proportion to
what each item asked for — so the longer string took the smaller cut.
Next to `fix/rpc-proxy-and-error-classification` the heading came out as
`DEL…` while the branch still showed thirty characters, which is exactly
backwards: the name is what the group is, the branch only what it
happens to be sitting on.
The header now measures itself against its real chrome the way a row
already does. The branch takes what it wants up to half the line, the
name keeps the rest above a 40px floor, and each is elided into its own
share — the branch keeping both ends, so two branches off one prefix
still read apart. `header_name_avail` holds the split and has three
tests; the counts measurement a row and a header both need moved into
`counts_width`.
Claude-Session: https://claude.ai/code/session_01E4EPKzHg1fm9HMmHkUYpER
The resting tint read as a disabled tab, not as a quieter one: a column
of 16% discs looked like a list of agents that had been switched off,
and the brand hue is how the eye tells a Claude row from a Codex row
before it reads either title.
The disc goes back to a solid fill of the agent's brand on every row,
lit or not, with the mark in the agent's own ink. `tab_avatar` loses the
`lit` argument and the three call sites stop threading selection into
it; `legible_on`, which only existed to ink a glyph on a tinted disc,
goes with it. The rest of the sidebar hierarchy work stays.
Claude-Session: https://claude.ai/code/session_01E4EPKzHg1fm9HMmHkUYpER
With the panel open those tiles stand in the band above it, over the
panel's own header — and that header's tab tiles are painted whenever the
panel is, so a band that grew two buttons under the pointer read as a
glitch beside them. macOS already struck this bargain when it moved the
tiles into the panel's title bar: once the panel is open they are part of
its chrome, not part of the strip's. Windows kept them hover-gated.
Position is unchanged; only the visibility gate is.
Claude-Session: https://claude.ai/code/session_01JRqYZ9E153WpSHGS2AW3BM
The bar is pinned to the bottom of the tile's own box, which only meets
the hairline when that box is as tall as the row. On macOS it is; in
`panel_title`, where Windows and Linux draw the same tiles, the wrapper
around them is only as tall as a glyph, so the bar floated a few pixels
above the line. Give that wrapper the row's height.
Keep `occlude` on the tile rather than on the full-height frame the bar
hangs off: over the whole row it would take the few pixels above and
below each glyph out of the title bar's drag region and hand them to
nothing.
Claude-Session: https://claude.ai/code/session_01VuYUPiDEhQX6aQ4WQZbEGn
The right panel's own title bar hid its two trailing tiles until the
pointer entered it, while the three tab tiles beside them were always
drawn — a row that grew two buttons on hover. Paint them with the rest.
Rule the row off from the content with the lighter of the two hairline
tiers, the one the panel's left edge already uses, and leave 8px under it
so the first row of content is not sitting on the line. The other
platforms draw this line on the title row, which keeps that distance with
its own text.
Say which tab is current with a bar under the glyph rather than with a
fill. The fill was the same grey the hover state paints, so the lit tab
and the tile under the pointer read as the same thing.
Claude-Session: https://claude.ai/code/session_01VuYUPiDEhQX6aQ4WQZbEGn
A pane that came back from a workspace switch came back empty. All that
was left was the shell banner and the `claude --resume … --fork-session`
line the pane was born with; the agent above it was still running and
still painting, but only in fragments, into an otherwise blank screen.
Switching tabs did nothing. Resizing the window fixed it, and only for
the tab that had focus, which had to be repeated tab by tab.
Nothing is lost on the wire. The replay arrives whole — every segment,
every byte — and is applied. What happens is that the client throws the
result away three frames later.
`replay_state` closes an attach by reporting the pane's shell state, and
a client that hears `active && at_prompt` scrubs the TUI modes it finds
in its grid, the alternate screen first (`stale_mode_resets`). For a
live report that is sound: a shell that is prompting cannot have a
full-screen program underneath it, so a `?1049h` still set in the grid
is residue from one that died without its `?1049l` — an `ssh` dropped
mid-`vim` — and sending the `?1049l` is the repair.
For a replayed report it is not sound. The alternate screen the scrub
finds there is the one the ring has just rebuilt, and `?1049l` does not
undo a stale mode: it swaps a live screen away and puts the primary
screen back in its place, which for an agent pane is precisely the
banner and the launch command. The program never learns any of this. It
goes on sending differential updates — only the cells it believes
changed — into a grid that no longer holds what those updates are
differences from, which is why the status line came back as fragments
with the middle blank. And a resize is the one thing that repairs it,
because a resize is the one thing that reaches the child: new geometry,
`SIGWINCH`, a full repaint. A tab switch reports geometry the daemon
already has, so it repairs nothing.
The stale claim comes from `st.shell.at_prompt`, which is only ever as
fresh as the last OSC 133 mark the pane produced. A shell that printed
its prompt (`133;B`) and then handed the terminal to a program that
sends no `133;C` of its own leaves that flag set for as long as the
program runs. The live path already declines to believe such a mark: the
pane reader drops `at_prompt` from any prompt mark that arrives while a
foreground command owns the pty. The replay was the one place that
re-asserted the stored value with no check at all.
It now asks the pty the same question, once, before it takes the state
lock, and reports a prompt only when nothing but the shell owns the
terminal. That keeps the scrub's purpose intact — when the shell really
is prompting there is no foreground command, the report goes out
unchanged, and a genuinely stranded alternate screen still heals on
reattach — while removing the case where the report contradicts a
program that is still there.
Claude-Session: https://claude.ai/code/session_01UUyWQXzcBAoBzaSX8pc7nU
A name typed into the create form cannot be sent as a rename: the workspace does
not exist on the machine yet, so the rename is answered `NotFound` and dropped,
and the create that follows names the workspace whatever `fresh_workspace_name`
rolled. That is #618, and the fix was to park the name on the window and have
the pull spend it — offering it to the create, and, if the machine came back
saying something else, sending it afterwards as the rename it had become. #604
then wired that answer straight to the switcher chip.
The trouble is that "the machine came back saying something else" is also what
walking into somebody else's workspace looks like. `settle_chosen_name` had two
facts to work with — a parked string and the name the machine answered with —
and neither of them says which workspace the name was meant for, or whether
anything was created at all. So it fired the rename at whatever workspace the
window had landed on. In #716 that was a workspace already holding nineteen
panes on another machine, and it came back named after the arriving client's
login. The report reads as one failure; it was two, and this is the second.
The parked name now carries the workspace it was typed for, and the pull now
says how the workspace got there. `pull_or_create` and `pull_workspace` answer
`Arrival::Created` when a create ran and `Arrival::Adopted` when the tree simply
had the workspace already, and the name is spent only when both agree: same
workspace, and a create to ride along with. Losing the create race still counts
as `Created` — a create did run for that workspace a moment ago, it just was not
this one, and its rolled codename is precisely what #618 exists to beat.
A name that does not match is left parked rather than dropped. Opening a
workspace runs two pulls at once, `start_prime`'s and `hydrate`'s, and only one
of them creates; taking the name on the adopting one would let the loser of that
race swallow it before the winner could spend it, which is the regression this
is trying not to reintroduce. Nothing leaks: `forget` drops the whole window
state when the window leaves the workspace.
`a_workspace_the_machine_already_had_still_takes_the_typed_name` is reshaped
rather than deleted. What it was really pinning is the create that answers under
another name, and that is still asserted, under a name that says so. The half it
asserted wrongly — that an adopted workspace takes the name too — is now pinned
the other way, once through `finish_prime` and once through `settle_hydration`,
which is the path the report actually came in through.
Left alone: the daemon still executes a `WorkspaceRename` from any client
without asking whether that client has ever pulled the tree. Like the tab-tree
half of #716, this fix is client-side, and an older build can still do it to a
machine running current main.
Claude-Session: https://claude.ai/code/session_01UUyWQXzcBAoBzaSX8pc7nU
The Ports section says nothing when a pane has no listeners, and it said
exactly the same thing when the code that looks for listeners never ran.
#731 is a report from inside that gap: a Go service started with `go run
main.go` on macOS serves requests, and tty7 shows no port.
The reported shape itself holds up. `snapshot()` walks the whole descendant
tree from the pane's shell, `go run`'s compiled binary sits at depth 2, and
the `lsof` invocation is the one that finds it. What did not hold up is
everything around that.
The walk stopped at 64 processes, and it is depth-first over children in
ascending pid order. A shell whose earlier children brought a crowd — a
build, a container runtime, an agent's worker pool — could spend the whole
budget before the traversal reached the newest child, and the newest child,
highest pid and visited last, is precisely the server someone started ten
seconds ago. The walk now runs to a far larger bound and the probe is asked
about all of it; only the list handed to the panel is cut back to 64 rows.
Every way the probe can fail arrived as the same empty vector. `lsof`
missing from the daemon's PATH read as "nothing is listening" — and the
daemon's PATH is not the shell's, while macOS keeps `lsof` in /usr/sbin,
the sort of entry a hand-written `export PATH=...` drops. So did a probe
that hung: `Command::output` has no deadline and this runs on the thread
answering `QueryProcs`, so one `lsof` wedged on a dead mount takes the whole
pane's process list with it, permanently. The probe now falls back to the
absolute paths, is bounded at three seconds, and says which of those
happened.
A server under `sudo` is visible as a process and invisible as a socket:
`lsof` running as this user cannot read another user's fds. The walk now
carries each process's effective uid, and a tree holding someone else's
process says so rather than claiming the pane is quiet.
`PaneProcs` grew a `probe` verdict, `serde(default)` so an older
`tty7-server` at the far end of a remote workspace still parses and its
silence still reads as a complete answer. The panel spends it on the one
muted line where it used to write "None", and `tty7 procs` — the command
the issue asks reporters to run — prints a note under the empty PORTS
table. No banner and no new colour: an honest empty state, not a warning.
Deliberately left alone: `lsof`'s exit status. It returns 1 for a pid it
could not locate, and a pane's tree loses processes between the walk and the
probe as a matter of course, so reading that as a broken probe would put a
doubt on screen every time a command finished. A non-zero exit that also
found nothing gets a debug log line and no more. The Windows path is
untouched beyond its new return type — `GetExtendedTcpTable` has no tool to
be missing and no subprocess to hang.
I could not reproduce #731, and none of these is proven to be the
reporter's bug. Each is a way the panel could be silently wrong, and the
verdict is what will make the next report say which one.
Claude-Session: https://claude.ai/code/session_01UUyWQXzcBAoBzaSX8pc7nU
The Info panel's CONVERSATION section, and the jump back into the
scrollback behind it, are gone: the row list, the anchors the client
kept for it, and the scanner that cut a batch of pty output at every
agent event.
What is left is what the outline rode on rather than owned. The hooks
still send their OSC 777, the daemon still reads it for the tab's status
dot, and `AgentEvent::prompt` still parses — nothing else read the rows.
Output batches now split for one reason (the parked-cursor repair), so
the two-scanner merge and its sort go with the section, and a replayed
snapshot parses in a single pass again.
Claude-Session: https://claude.ai/code/session_01E4EPKzHg1fm9HMmHkUYpER
A pane can come out from under its tab with its shell still running — an
interrupted `tty7 run`, a `ws rm` that could not hang everything up, or a client
that closed nineteen tabs whose shells were all alive (#716). `pane ls --all`
has been able to *show* those for a while, but everything the CLI offered to do
about one was to kill it: `pane close %<id>`, or `pane close --orphans` for the
lot. The shells were fine. There was simply no verb that put one back on screen,
so recovering meant recreating tabs by hand and reaping the originals.
`tab new` grows a `--pane` that builds the tab around a pane that is already
running instead of spawning a shell for it. Nothing new had to be invented on
the wire: `ControlRequest::TabCreate` has always taken a `PaneSeed` with a pane
id in it, which is how `run --keep` files its pane into a tab.
The part that needed designing is where the seed comes from. `tab_close`
retains the orphaned panes out of `m.panes` at the same moment it drops the
tab, so by the time anyone wants a pane back the tree has already forgotten its
record — cwd, title, shell. Reading the seed off the tree would therefore work
for an interrupted `run` and fail for exactly the case this verb exists for. It
is rebuilt from the live pane registry instead, which still has the pane
because the pane is still running, and which is the same list `pane ls --all`
walks. That does mean `ssh_spec`, `agent` and `shell` are not recovered — the
registry never carried them. They cost nothing while the shell lives, since the
tab is a view onto a pty that is already there, and only matter if the pane
later dies and something tries to restore it from the seed. Reconstructing them
from a running pty is a different problem; a tab you can see beats a shell
nobody can reach.
Two refusals rather than one guess: a pane the server is not running cannot be
re-homed, and neither can one a tab already holds — that is what `pane split`
is for, and accepting it would put a single pane in two places in the tree. With
no workspace named the pane goes back to the one it was spawned for, which is
the `owner` that `pane ls --all` already prints; `$TTY7_WS` cannot help here,
because a shell recovering from this is by definition not inside tty7.
The `pane ls --all` footer now names the way back as well as the two ways to
kill, since the listing is where an orphan is found and so is where the recovery
has to be written down.
Deliberately not done here: the switcher's orphan rows still carry only a Close
button. Adopting from the GUI is not the same one-line change — the row lists
orphans machine-wide while a window speaks for one workspace, and a pane may
only be attached by the workspace that owns it, so the button has to decide
where the tab goes before it can build one. That is its own piece of work.
Claude-Session: https://claude.ai/code/session_01UUyWQXzcBAoBzaSX8pc7nU
Three things had to line up for a password sheet that keeps reappearing
after the connection has already succeeded, and cannot be closed. Two of
them are here; the third was the reason closing it never helped.
The connection cache keys one slot per host, and that slot's mutex is
what makes a reconnect ask for a password once rather than once per pane
— everyone dialling the same host queues on it, and all but the first
find the connection the winner left behind. Eviction removed the map
entry outright. A dropped TCP connection kills every pane riding it at
the same instant, so all of them reach the dead-reuse branch in
`run_session` together: the first removed the entry, its `open_connection`
inserted a fresh mutex, and the pane a moment behind it removed *that*
one — the mutex a handshake was already holding — and inserted another.
Each pane ended up alone on a mutex of its own, ran its own handshake and
raised its own prompt. Answer one and the link comes up; the rest are
still queued behind it. Eviction now empties the slot instead of
replacing it, and leaves a slot somebody is dialling on completely alone.
The entry outliving its connection is what the map already looked like
everywhere else, and `routes()` has always reported such a slot as
disconnected rather than omitting it.
The second is what happened on close. A declined prompt failed only the
method that raised it, and `authenticate` walked on to the next one — but
`password` and `keyboard-interactive` are one question asked two ways, and
a server offering both wants the same secret either way. Closing the
password sheet put a keyboard-interactive sheet up asking for the same
password. Nobody declines a *method*, so a declined prompt now ends the
attempt, with a reason distinct enough for a caller to recognise.
That caller is the workspace supervisor, which reconnects on a clock and
treated the refusal as a transient failure: it dialled again a second
later, and every thirty seconds after that, for the rest of the session.
It now suspends the machine instead. The strip already says why and
offers Retry, which is the user asking to be asked again.
A key passphrase is left alone deliberately. Closing that sheet declines
one key, and the methods still to come ask a different question — someone
who cannot remember a passphrase is usually closing it precisely to be
asked for a password instead. So is the fact that a password is only kept
across reconnects when "Remember" was ticked: that is a choice about
storing a secret, not a bug.
Claude-Session: https://claude.ai/code/session_01UUyWQXzcBAoBzaSX8pc7nU
A pane's screen comes back on re-attach out of the replay ring, and the ring is
a window: eight megabytes wide, dropped from the front as it fills. That is the
right shape for text, which is only worth what is still on screen, and the
wrong one for modes. A full-screen program announces itself exactly once —
`btop` sends `?1049h` and its mouse-reporting modes when it starts and then
does nothing but refresh — so a long enough run of refreshes pushes the only
copy of that announcement out of the front of the ring. What the client
replays is then a screenful of alternate-buffer frames with nothing left to say
they belong on the alternate buffer: it paints them onto its primary screen
with reporting off, and `wheel_route`, which reads exactly those modes, sends
the wheel to the scrollback of a screen that has none. That is the "a screen
that should not scroll starts scrolling" in the report.
`replay_state` already refuses to rely on the ring for anything that matters —
cwd, prompt state, the remote context, the agent, the exit — because all of
those are facts about the pane rather than bytes on it. The modes are the same
kind of fact and were the exception, so the daemon now folds the bytes it hands
the ring into a small tracker (`core::term_modes`) and `replay_state` re-sends
what is still on. Tracked are the modes that decide input routing or which
buffer is on screen: the alternate screen in its three spellings, the mouse
reporting level and its encodings, alternate scroll, DECCKM, focus reporting
and bracketed paste. They are replayed in the order the application set them,
because the emulator treats the reporting modes as a level and not as
independent bits, so the last one set has to be last here too.
The frame goes *ahead* of the ring rather than after it. That way the replayed
frames are painted into the buffer they were drawn for, and re-entering an
alternate screen the ring turns out to still carry is a no-op in the emulator,
so a prefix and a ring that both carry the mode cannot fight. Where the ring
does still carry a toggle it wins on its own terms, since the fold runs over
every byte the pane ever wrote and therefore agrees with the ring's last word
on any mode the ring still mentions.
Cursor visibility (`?25`) and autowrap (`?7`) are deliberately not tracked. Any
frame of a running TUI repaints them within milliseconds, whereas restoring a
stale `?25l` would leave a shell with an invisible cursor — a worse failure
than the one being fixed, and one the existing `restore_preamble` already goes
out of its way to avoid. A daemon handoff starts the fold empty rather than
carrying it, so a pane adopted across a daemon restart is no worse off than it
is today; the ring it carries is all it ever had.
Claude-Session: https://claude.ai/code/session_01UUyWQXzcBAoBzaSX8pc7nU
The repair that puts back the cursor a conhost repaint parks was gated on
`const REPAIR_PARKED_CURSOR: bool = cfg!(windows)` — a compile-time answer
about the platform the client was built for, when the question it is standing
in for is what kind of pty this pane is attached to. Those are not the same
question, and a Windows client's panes are not all alike. A local shell is a
ConPTY and so is `wsl.exe` or an `ssh` client running inside one, because they
are ordinary programs in the same conhost-rendered buffer. A pane on a remote
`tty7-server` is not: a remote workspace only installs onto Linux or macOS
(`asset_for_uname` refuses everything else), so its pty is raw. Nor is a
native-SSH pane, which the local daemon dials but opens no pty for — it bridges
an ssh channel straight through.
The repair is written for what conhost does: it brackets a frame in `?25l` …
`?25h` and, on the frames where it did not paint the cursor, commits the show
wherever the last erase left it. Applied to a raw pty it is not a correction
but a corruption, because there the application owns the cursor and may
deliberately end a repaint on the text it just wrote. Vim opens its `:` command
line exactly that way and then echoes the following keystrokes as bare bytes,
so moving the cursor back to where the repaint hid it drops the `wq` two rows
up, onto the line being edited. That is #430 again, on the path the Mac fix
never covered: a Windows client talking to a Linux host.
So the decision moves to a per-pane `PtySource`, resolved at runtime from the
route the pane was spawned or attached on and carried to the reader as a shared
flag. `RemoteContext` is a second source of the answer, because the route
cannot supply it: a native-SSH pane is spawned and attached through the local
daemon like any other, so a window reopening onto an existing one by pane id
has nothing else to go on. Learning `RemoteKind::NativeSsh` turns the repair
off for good — one way, since the far end of an ssh channel never becomes a
local pty later, and since an `ssh` *command* (`RemoteKind::Ssh`) is a program
inside a ConPTY and must keep the repair. A relink reuses the pane's existing
answer rather than recomputing one, for the same reason: the pty on the far
side is the pty it always was.
Nothing about when a cursor counts as parked changed — `ParkedCursorScanner`
and `ParkedCursorRepair` are untouched, and the Windows behaviour they were
written for is unchanged for every pane that really is on a ConPTY. The tests
that covered them move out of the `cfg(unix)` module and onto the socket-pair
harness that already runs on both platforms, so both answers are now driven
directly instead of one of them being whatever the host happened to compile:
a conhost frame on a ConPTY still parks, the same frame off a raw pty does not,
vim's `:wq!` lands on the command line, and a native-SSH context turns the
repair off mid-stream.
Claude-Session: https://claude.ai/code/session_01UUyWQXzcBAoBzaSX8pc7nU
`MachineStore::persist` serialises the whole document and lands it with
`write_atomic_private`, so the file on disk is never torn — but the document it
replaces is simply gone. The tree is rewritten whole on every mutation, which
means the write that loses a layout is also the write that erases the only copy
of it. That is what turned #716 from an annoyance into a lost afternoon: a
client's arrival queued nineteen `TabClose`s, each one persisted, and by the
time anyone read `machine.json` there was nothing anywhere on the machine that
remembered what the workspace had looked like.
`persist` now rotates the document it is about to replace into a small ring of
backups beside it — `machine.json.bak`, then `.bak.1` and `.bak.2` behind it —
before the new one is written.
Two things decide whether such a ring is worth anything. The first is what
"previous good" means. It cannot mean "the last document that parsed": an
emptied tree parses perfectly and is exactly the state you want to recover
*from*, so validity is no signal at all. Age is the only signal available, so
the ring is spaced: a generation is taken only when the newest one is at least
five minutes old. Without that spacing the failure mode above — a burst of
writes seconds apart — would have rolled three copies of the damage through the
whole ring before a human noticed. With it, the oldest generation is a quarter
of an hour of history, and three generations is where the ring stops so a file
rewritten every few seconds does not grow a history without bound.
The second is the atomicity of the rotation itself, since a rotation that can
lose both copies is worse than none. The live file is never renamed, only read:
at every point in `keep_a_generation` the tree is still completely at its own
path, and the new generation lands through `write_atomic_private` — a sibling
temporary renamed into place, which also means the copies inherit the 0600 the
live tree is written under rather than widening anything. A crash mid-rotation
costs at most one backup generation and never the tree. A backup that cannot be
written is logged and the new document is persisted anyway; a machine with no
backup still has to work.
`load_machine` now also falls back to the newest generation that parses when the
live document is unreadable or corrupt, instead of starting from an empty tree.
Deliberately only for those two cases: a tree that parses always wins, however
empty it is, because that is the case a human has to judge — which is why the
files are plain JSON under obvious names, ready to be copied back by hand.
Claude-Session: https://claude.ai/code/session_01UUyWQXzcBAoBzaSX8pc7nU
git_click was inserted between the function and its doc block, so the
block explaining why the setting is one setting ended up on the wrong
function. Move the helper above it.
Claude-Session: https://claude.ai/code/session_01Ak6Lnzf3EGErJZmG51Rxbo
Opening a second tab on a machine tty7 was already connected to and already
serving cost the same wait as the first one. The SSH connection is reused, so
none of that wait was handshake cost: every route called `ensure_remote_server`
unconditionally, and that runs the whole installer probe again — `uname -sm`,
an SFTP realpath for the home directory, an SFTP stat, a control probe that
spawns the server binary, and `check_running_build`, which walks `/proc/[0-9]*`
with a `readlink` per PID and shells out to `ps` on the machines that have no
`/proc`. Five serial round trips before the pane's own channel opened, to
re-learn what the pane before it had just learned.
WSL fixed exactly this in #479 by remembering where a distro's server was last
proved to be. SSH now does the same, with one difference that matters: a distro
name is the whole identity of a WSL target, but an SSH connection can die and
be replaced under the same key, so the note is kept on the `SshConnection`
rather than in a map beside its key. Keying by connection generation is then
not a discipline anyone has to keep — a reconnect is a new `SshConnection` with
an empty slot, and nothing has to remember to forget.
Memoizing must not quietly cancel the version check, which is the one thing
that could make this a bad trade. Three things keep it honest. The note carries
the build mismatch the probe found and re-files it on every hit, because the
warning is raised inside `Installer::run` and each route drains its own sink —
without that, only the first pane on a connection would ever hear that a
different build is serving the machine, and every window after it would attach
in silence. `replace_remote_server` and `restart_remote_daemon` forget before
they act, not after, so a restart that fails halfway leaves the next pane
looking rather than trusting a note written before the upheaval. And the router
forgets when a routed link closes without the remote sending a byte, the way it
already does for a WSL bridge: `exec` succeeds whatever the command turns out
to be, so a binary deleted or moved since the probe is discovered exactly
there.
A failed probe is deliberately not remembered. A host that was briefly
unreachable, or an install the user declined once, must not pin every later
pane on that connection into the same failure — the slot is written only when
the probe got all the way through. The note carries the binary path and the
mismatch and nothing else: `installed`, `launched` and `confirmed` describe an
event rather than a state, and serving them again to a later pane would only
make the log lie.
Left alone on purpose: the probe itself, which is unchanged and still the only
thing that decides what a pane runs; the WSL memo, which keeps its own shape;
and the macOS-server half of #695, which shipped in v26.9.1.
Claude-Session: https://claude.ai/code/session_01UUyWQXzcBAoBzaSX8pc7nU
The switcher card had the sidebar's problem in a popover: the loudest
marks were the filled `this window` / `open` / `active` pills — states
dressed as buttons — and the full-ink diff counts, while the keyboard
cursor sat on the `pressed` rung one step under `cursor`, close enough
to a hovered row that the focused column was anybody's guess.
- Badges become words in the caption ink; only "taken over" keeps its
warning colour.
- The picked row takes the `cursor` rung the ladder set aside for a
palette's keyboard row.
- The three `muted_foreground.opacity(0.7)` inks (≈2.6:1) are gone; the
second line is subordinate by size, not by a grey under the floor.
- A workspace row's second line keeps its timestamp: the path is what
truncates, so a narrow row no longer ends in a dangling `·`.
- Diff counts use `resting_ink` on the popover fill, as the sidebar does.
Claude-Session: https://claude.ai/code/session_01Ak6Lnzf3EGErJZmG51Rxbo
Every line in the sidebar sat at the same 4.5:1 grey — tab title, branch
line, group header, search placeholder — so the only things that stood
out were twelve identical brand-orange agent discs and twelve copies of
the same `+94 −26`, neither of which says which tab matters.
- Titles rise to a 7:1 floor (AAA) with a cap that keeps the selected
label its `TEXT_STEP`; captions stay at `TEXT_RESTING`. A new test pins
the step between them.
- The sidebar gets its own selection ladder (`SIDEBAR_SELECTED` 1.50);
the window's signed-off 1.30 rung is untouched and its Dracula pin now
checks the constant rather than the rail's fill.
- Agent avatars rest as a 16% brand tint with the mark in brand ink and
light up solid only on the active tab or an agent that is waiting.
- Diff counts render in `resting_ink`: same hue, blended toward the
caption, walked back to the 4.5 floor where needed.
- A group whose rows all share one branch and diff says so once on its
header; rows with no status yet do not vote, so ⌘T no longer flips the
group twice while the poll comes back.
- Group headers get 12px above, the count shows only when folded, and
the two sub-floor `.opacity()` captions are gone. The workspace
switcher name reads at the headers' weight instead of inheriting the
title ink.
Claude-Session: https://claude.ai/code/session_01Ak6Lnzf3EGErJZmG51Rxbo
l0ng-ai
hhdebb