Merge pull request 'Colour the window's frame, inset Hosts like its neighbours, drop Pins' (#9) from claude/title-bar-color-windows-6d386c into main

Reviewed-on: #9

Directory.Build.targets

@@ -0,0 +1,68 @@
+<Project>
+
+  <!--
+    ◆ THE TRIMMER'S VERSION IS PINNED HERE BECAUSE OTHERWISE THE LOCK FILES ARE NOT LOCKED.
+
+    Microsoft.NET.ILLink.Tasks is not referenced by anything in this repository. The SDK adds it
+    on its own to any project that sets IsTrimmable or IsAotCompatible — DodoSSH.Contracts and
+    DodoSSH.Crypto do, and the Android head gets it from trimming being on by default there — and
+    the version it asks for is whatever the running SDK happens to bundle. That version lives in
+    the SDK's own Microsoft.NETCoreSdk.BundledVersions.props, as a KnownILLinkPack item.
+
+    Which makes it a dependency whose version is a property of the toolchain rather than of this
+    repository, and that is the whole problem: packages.lock.json records it as a Direct reference
+    with a requested range, so the lock file silently means "whichever SDK last ran a restore".
+    global.json says rollForward: latestMinor, so CI's setup-dotnet installs the newest 10.x SDK
+    that exists on the day it runs. The moment .NET ships a servicing release, CI's SDK asks for a
+    version the committed lock files do not have, and the locked-mode restore in ci.yml fails with
+    NU1004 before a single file is compiled.
+
+    That is not hypothetical. It closed the whole pipeline: main's run 125 and every open pull
+    request went red together, on
+
+        error NU1004: The package reference Microsoft.NET.ILLink.Tasks version has changed
+        from [10.0.10, ) to [10.0.11, ).
+
+    with nothing in any of those commits touching a package. .NET had shipped SDK 10.0.400, which
+    bundles ILLink 10.0.11 where 10.0.302 bundled 10.0.10, and setup-dotnet installed it the next
+    time anything ran.
+
+    Worse than the outage is the shape of the repair without this pin. Regenerating the lock files
+    holds only until the next servicing release, and it cannot be done from a machine whose newest
+    SDK is older than the runner's: a restore on 10.0.302 writes 10.0.10 straight back and re-breaks
+    CI, so the recorded version becomes a fact about whoever ran restore last rather than about this
+    repository. That is exactly the state locking exists to prevent, and it is not a hypothetical
+    either — every SDK installed on the machine this pin was written on tops out at 10.0.302.
+
+    Pinning it makes the recorded version a decision this repository made, reviewable in a diff
+    like every other version in Directory.Packages.props, and identical on every machine whatever
+    SDK it has. Moving it is then a deliberate edit here plus a regenerated lock file, which is the
+    same ceremony any other dependency bump gets.
+
+    It is an Update on the SDK's item rather than a PackageVersion in Directory.Packages.props, and
+    it has to be: the reference is implicit, so the SDK supplies the version itself and central
+    package management never gets asked. ProcessFrameworkReferences reads @(KnownILLinkPack) when
+    it runs, which is why this lives in Directory.Build.targets — the item does not exist yet while
+    Directory.Build.props is being evaluated.
+
+    Keep this within a patch or two of the runtime the SDK ships. It is the trimming analyzer and
+    the ILLink task, so a small skew is harmless, but a version far behind the framework being
+    analysed is a real way to miss a trim warning.
+  -->
+  <Target Name="PinTheILLinkPackVersion" BeforeTargets="ProcessFrameworkReferences">
+    <!--
+      Inside a target, and not for tidiness. The SDK ships one KnownILLinkPack per target framework
+      and they all share the identity "Microsoft.NET.ILLink.Tasks", so the TargetFramework metadata
+      is the only thing telling net10.0's entry from net8.0's. A condition on %(...) is item
+      batching, which MSBuild permits in a target and rejects during evaluation with MSB4191 — so
+      an ItemGroup at the top of this file cannot express "only the net10.0 one" at all, and the
+      unconditioned Update it would have to become rewrites every framework's entry.
+    -->
+    <ItemGroup>
+      <KnownILLinkPack Update="Microsoft.NET.ILLink.Tasks"
+                       Condition="'%(TargetFramework)' == 'net10.0'"
+                       ILLinkPackVersion="10.0.11" />
+    </ItemGroup>
+  </Target>
+
+</Project>

docs/design-import-gaps.md

@@ -300,7 +300,7 @@ the chrome, hosts and terminals, file transfer, the vault, teams, and preference
 > | The status bar's negotiated cipher, host-key algorithm and key/credential name | ◆ **Shipped, on both surfaces, with three honest deviations.** `ISshConnection` and `ISftpSession` now both carry `Cipher` — the server-to-client algorithm off SSH.NET's own `ConnectionInfo.CurrentServerEncryption`, captured once at construction because a rekey is not an event SSH.NET raises — and `TerminalWorkspace.GetSessionFacts` hands the cipher and the host key's algorithm back to the shell the moment a session opens; `VaultViewModel.TryBuildAuthentication` now threads the authenticating key's or credential's own `Label` into `HostAuthentication.IdentityLabel`, all the way to `MainWindowViewModel`'s surface-aware `SessionCipher`, `SessionHostKeyAlgorithm` and `SessionIdentityLabel`, composed into one `SessionIdentityText` run for the status bar. Three deviations from the mock, not omissions: the algorithm prints exactly as negotiated (`ssh-ed25519`), not the design's shortened `ed25519`, because trimming it would be an edit to a string this client did not choose; the run is plain text rather than the design's clickable element, because there is no pin-details modal for a session that is already open, and drawing a click target for a screen that does not exist would itself be a fabrication; and a typed-password session — nothing filed in the keychain to name — shows the host-key algorithm alone, with no `·` after it, because there is no item behind the dot. |
 > | S3 dimmed in the design's own switcher | **Enabled.** The mock leaves S3 as future work; this application already has bucket browsing, so SSH, SFTP and S3 are a true three-way segment, wired to `IsSshShowing`, `IsTransfersShowing` and `IsBucketsShowing` exactly alike. |
 > | The S3/Buckets screen | **Did not get the session shell in v5b.** `TransfersScreen` serves both SFTP and S3 today and only the SFTP usage in `MainWindow.axaml` sat inside the new tab row/header/status bar/sidebar; the S3 usage was unchanged at the time. **v5c gives it the shell's own look without the machinery** — a 26-pixel padded, bordered, radius-12 container and nothing past that, since a bucket has no tab to close, no host to head a card with and no pin for a sidebar to show; see the v5c section, below. |
-> | No pins destination in the design at all | **Kept anyway.** The rail still carries Pins — `KnownHostsScreen` — because the mock has no screen for approved host keys and this application's has to stay reachable. |
+> | No pins destination in the design at all | **The rail agrees with the design now.** `KnownHostsScreen` is still built and still reachable — from **Host keys** on the Keys screen's own header, which was always the second way in — but the rail's Pins row is gone. It was kept through v5b on the grounds that the mock has no screen for approved host keys, which is a reason for the screen to exist and was never a reason for a rail entry once the keychain had a door to the same place. Two rail rows landing on one screen is a rail that has to be read twice. |
 > | The popover's Settings and Preferences rows, and the design's own Settings-* family of screens | **Landed in v5c.** What was two doors to one room in v5b — Settings and Preferences both opening the same bare `Preferences` screen — is now two of three doors onto their own settings pages: Settings opens General, Preferences opens Preferences, and a third row, Vaults, opens Vaults. All three are real, distinct pages inside one settings mode; see the v5c section, below. |
 > | `· Org` after the user chip's name, and a `Primary` tag on a vault row in the popover | Neither. There is no organisation concept behind a vault — only the vault itself — and no vault is distinguished as primary; the popover's vault rows are the existing shown-vaults toggles, restyled. |
 > | The design's titlebar, which has nowhere for a sync indicator | `SYNCED` stays, on the titlebar's right side, ahead of the window's own minimise/maximise/close buttons — the one thing this titlebar keeps that the design's own does not draw at all. |
@@ -720,3 +720,24 @@ grid of cards with a drawer — see above. The split it describes did not change
 running, so a tab list rebuilt per unlock would lose track of sessions that are still connected — the very
 sessions the unlock screen already counts. `TerminalWorkspace` gained `SessionActivated` on the wire,
 `IsSessionLive`, and a `SessionEnded` event so a tab can stop claiming to be connected.
+
+---
+
+## v5c-4 — two more, asked for after living with v5b
+
+**The session shell's host header is gone, and it is a deliberate departure from the design.**
+`Terminal.dc.html` and `SFTP.dc.html` both draw a 60-pixel row above the pane carrying the address on the
+left and a cross-surface button on the right, and v5b shipped it as `SessionHeader.axaml`. Both of the two
+facts it held now live at the head of the sidebar beside the pane — the address as its own line, and the
+button stretched across the column under it — and the pane is 60 pixels taller for it. The reasoning is the
+one the design cannot see from a mock: this is a window somebody keeps a terminal open in all day, and a
+full-width strip repeating an address the tab already names was the cheapest 60 pixels in the layout to give
+back. `LayoutHarness.SessionScreenHeight` no longer subtracts a header, for the same reason it stopped
+subtracting the retired window-wide tab strip.
+
+**The sidebar closes, which the design has no state for.** 300 pixels of a 1081-pixel minimum is a lot to
+spend on a list that is often two rows long, so `MainWindowViewModel.IsSessionSidebarOpen` folds the column
+to a 34-pixel rail carrying the chevron that brings it back — a rail rather than nothing, because a panel
+that vanishes without trace is one people report as lost. The choice is written through to
+`ClientSettings.SessionSidebarOpen` rather than held for the session: it is a decision about how much of the
+window a terminal gets, and one that had to be made again on every launch would not really be on offer.

docs/manual-checks.md

@@ -28,8 +28,9 @@ a phase had nothing left for a person to do, which is the good outcome rather th
 
 ### 1.1 No screen is sliced at the WebView's left edge · **the important one**
 
-Open two terminals, then visit every nav rail entry in turn — Hosts, Keys, Pins, Snips, Logs — and both of
+Open two terminals, then visit every nav rail entry in turn — Hosts, Keys, Snips, Logs — and both of
-the switcher's other two segments, SFTP and S3, at the rail's own head.
+the switcher's other two segments, SFTP and S3, at the rail's own head. The pins screen is no longer a rail
+entry; reach it from **Host keys** on the Keys screen's header and check it the same way.
 
 **Pass:** each screen draws whole, its buttons all clickable, and the nav rail stays up the left edge for
 every one of them. Since v5b's chrome pass the rail is permanent furniture — it no longer collapses for
@@ -2423,7 +2424,9 @@ script warns rather than failing when that is legitimate, which is the first rel
 ### 16.7 The update arrives, and the restart lands in it · **the whole point of the work**
 
 With v0.1.0 installed and running, a vault unlocked, a host change made, and **a terminal open**, publish
-v0.1.1 (`-Upload`). Then press CHECK NOW on Settings → General rather than waiting six hours.
+v0.1.1 (`-Upload`). Then press CHECK NOW on Settings → General rather than waiting six hours. Closing and
+reopening the application does the same thing without the button: the first pass of the loop runs at launch,
+so a client started after a release finds it without anybody asking.
 
 **Pass:** the progress bar moves, the banner appears above the status bar, and — the part to actually watch
 — the terminal **reflows cleanly rather than being sliced**, with the remote seeing the smaller row count.

docs/platform-flags.md

@@ -712,6 +712,30 @@ The lasting hazard is the first paragraph and not the fix. Any change to a share
 to a lock file this repository cannot verify from a machine without the Android workload, and it will go
 on being noticed later than every other one.
 
+**A lock file can go stale with nothing in this repository changing, because `Microsoft.NET.ILLink.Tasks`
+is versioned by the SDK and `global.json` lets the SDK float.** The reference is implicit — nothing in any
+`.csproj` asks for it — and its version tracks the runtime patch band, while `global.json` pins only
+`10.0.100` with `rollForward: latestMinor`. So `setup-dotnet` installs whatever the newest 10.x SDK is on
+the day, and the moment that SDK's band moves, locked-mode restore stops:
+
+```
+error NU1004: The package reference Microsoft.NET.ILLink.Tasks version has changed
+from [10.0.10, ) to [10.0.11, ).
+```
+
+It named `DodoSSH.Client.Android`, `DodoSSH.Contracts` and `DodoSSH.Crypto` — the three lock files that
+carry the entry — on a commit that touched none of them and no dependency at all.
+
+The fix is `--force-evaluate` on those three, **from a machine whose SDK is at least as new as the
+runner's**, which is the part that is easy to get wrong: a `--force-evaluate` from an older SDK rewrites
+the lock at the older version, changes nothing, and looks like it worked. Check `dotnet --version` against
+the version in the error before believing a regeneration.
+
+This will recur on every SDK patch that moves the band. It is the accepted cost of letting the SDK float:
+the alternative is pinning an exact SDK in `global.json`, which trades a recurring lock-file bump for a
+recurring toolchain bump and makes every contributor install one specific SDK. Neither is free, and this
+repository has chosen the floating side deliberately.
+
 **.NET for Android cannot be built on a musl host, and this project's runner is Alpine. Every message the
 toolchain produces on the way to saying so names a missing file that is present.** Three CI rounds went
 into this and the first two fixed symptoms, so the messages are worth reading in the order they arrive.

src/DodoSSH.Client.Android/packages.lock.json

@@ -74,9 +74,9 @@
       },
       "Microsoft.NET.ILLink.Tasks": {
         "type": "Direct",
-        "requested": "[10.0.10, )",
+        "requested": "[10.0.11, )",
-        "resolved": "10.0.10",
+        "resolved": "10.0.11",
-        "contentHash": "f5VCIE7AJpd5YvzNTeMGVzQIgyE9tX+AreTYwQF+REbu+DZo/2Ae+jNSwhPEYrVz6RRkd7y8ubXjk6Nn6Ka+Cg=="
+        "contentHash": "IBf7lbovvjGWVWXZX5cJ/cO0WXbId0Zq4BuSeT94mGZuOAP66oMeH9PTBZ9Jpp3Jb6jtK0qm/NyUbPRo1gC/wQ=="
       },
       "MinVer": {
         "type": "Direct",

src/DodoSSH.Client.App/App.axaml

@@ -475,11 +475,34 @@
       <Setter Property="Background" Value="{StaticResource Track}" />
     </Style>
 
+    <!--
+      The user popover itself: the panel the rail's chip opens, in this window's own idiom rather than the
+      theme's. The shared MenuFlyoutPresenter rule further down this file gives every popup Chrome and a
+      4-pixel radius, which is right for a context menu and wrong for this one — the design draws the account
+      menu as a rounded card, the same radius-12 shape as every other floating surface here. Reached with
+      FlyoutPresenterClasses from NavRail.axaml rather than by widening that rule, so a right-click menu two
+      screens away does not quietly become a card as well.
+    -->
+    <Style Selector="FlyoutPresenter.poppanel">
+      <Setter Property="Background" Value="{StaticResource Raised}" />
+      <Setter Property="BorderBrush" Value="{StaticResource BorderMid}" />
+      <Setter Property="BorderThickness" Value="1" />
+      <Setter Property="CornerRadius" Value="12" />
+      <Setter Property="Padding" Value="8" />
+    </Style>
+
     <!--
       A row inside the user popover: a vault switch, "New vault", Settings, Preferences, Vaults, Logout. All
       six share one shape — flat, a track fill under the pointer, 8 pixels of rounding — because the popover
       draws them as one list and a row that looked different from its neighbours would read as a separator
       that is not one.
+
+      ◆ FLAT MEANS SAYING SO, which this rule did not. It set a corner radius and a padding and left the
+      Background alone, so every row wore the Fluent theme's own button fill and its border: six raised pills
+      stacked in a menu, where the design draws six lines of text that light up under the pointer. The hover
+      rule below was already right and was simply invisible against a fill that was there all along. Set on
+      the ContentPresenter as well as on the Button, the same as Button.flat does and for the same reason —
+      the theme's template binds its own brush there, and a Background set only on the control loses to it.
     -->
     <Style Selector="Button.poprow">
       <Setter Property="HorizontalAlignment" Value="Stretch" />
@@ -488,14 +511,20 @@
       <Setter Property="Padding" Value="11,4" />
       <Setter Property="CornerRadius" Value="8" />
       <Setter Property="MinHeight" Value="20" />
+      <Setter Property="Background" Value="Transparent" />
+      <Setter Property="BorderThickness" Value="0" />
     </Style>
     <Style Selector="Button.poprow /template/ ContentPresenter#PART_ContentPresenter">
+      <Setter Property="Background" Value="Transparent" />
       <Setter Property="BorderThickness" Value="0" />
       <Setter Property="CornerRadius" Value="8" />
     </Style>
     <Style Selector="Button.poprow:pointerover /template/ ContentPresenter#PART_ContentPresenter">
       <Setter Property="Background" Value="{StaticResource Track}" />
     </Style>
+    <Style Selector="Button.poprow:pressed /template/ ContentPresenter#PART_ContentPresenter">
+      <Setter Property="Background" Value="{StaticResource Track}" />
+    </Style>
 
     <!--
       The check square beside a shown vault in the popover — magenta rather than the accent, because the
@@ -594,10 +623,13 @@
     </Style>
 
     <!--
-      ── v5b: THE HOST HEADER'S "OPEN SFTP" / "OPEN TERMINAL" GHOST BUTTON ───────────────────────────────
+      ── v5b: THE "OPEN SFTP" / "OPEN TERMINAL" GHOST BUTTON ─────────────────────────────────────────────
       A ghost button distinct from <c>Button.ghost</c> above: this one's resting border is <c>BorderHover</c>
       rather than <c>BorderMid</c> — the mock's own inset ring for this one control — and the design gives it
-      no filled hover, only the border turning to the accent. See <c>SessionHeader.axaml</c>.
+      no filled hover, only the border turning to the accent.
+
+      Named for the host header it was drawn for, which v5c-4 retired; the button itself moved intact to the
+      head of the session sidebar and is stretched across that column there. See <c>SessionSidebar.axaml</c>.
     -->
     <Style Selector="Button.headerghost">
       <Setter Property="Height" Value="32" />
@@ -643,6 +675,30 @@
       <Setter Property="Background" Value="{StaticResource Track}" />
     </Style>
 
+    <!--
+      ── v5c-4: THE SIDEBAR'S OWN CLOSE AND REOPEN ────────────────────────────────────────────────────────
+      One class for both, because they are one control in two states — a 26-pixel square carrying a chevron,
+      at the head of the column when it is open and at the head of the rail when it is not. Square rather
+      than the 33-tall rows below it: it is chrome belonging to the panel, not an entry in the list the panel
+      is holding, and matching the rows' shape would have offered it as one.
+    -->
+    <Style Selector="Button.sidebargrip">
+      <Setter Property="Width" Value="26" />
+      <Setter Property="Height" Value="26" />
+      <Setter Property="MinWidth" Value="0" />
+      <Setter Property="MinHeight" Value="0" />
+      <Setter Property="HorizontalAlignment" Value="Center" />
+      <Setter Property="HorizontalContentAlignment" Value="Center" />
+      <Setter Property="VerticalContentAlignment" Value="Center" />
+      <Setter Property="CornerRadius" Value="8" />
+    </Style>
+    <Style Selector="Button.sidebargrip /template/ ContentPresenter#PART_ContentPresenter">
+      <Setter Property="CornerRadius" Value="8" />
+    </Style>
+    <Style Selector="Button.sidebargrip:pointerover /template/ ContentPresenter#PART_ContentPresenter">
+      <Setter Property="Background" Value="{StaticResource Track}" />
+    </Style>
+
     <!--
       The "+ Pin folder" / "+ Add Snip" row at the foot of each section: 30 tall rather than 33, and its own
       quieter foreground — the mock draws these as the same greyed-out "add" idiom in both sections.
@@ -857,18 +913,30 @@
       into a grid: equal columns, and a card that grew a third line of tags is taller than its neighbours
       rather than narrower.
 
-      ◆ 224 IS DERIVED, and the arithmetic is written out because getting it wrong is invisible. The grid's
+      ◆ 214 IS DERIVED, and the arithmetic is written out because getting it wrong is invisible. The grid's
-      column at the window's minimum is 1016 less the rail's 190 and the drawer's 320, which is 506. The
+      column at the window's minimum is 1081 less the rail's 255 and the drawer's 320, which is 506. The
-      scrolling stack inside it takes 16 of margin on each side, and the vertical scrollbar takes its own —
+      scrolling stack inside it takes 26 of margin on each side, and the vertical scrollbar takes its own —
-      call the usable width 474. A WrapPanel fits floor(474 / (Width + 10)) per row, so two columns needs
+      call the usable width 454. A WrapPanel fits floor(454 / (Width + 10)) per row, so two columns needs
-      Width no more than 227.
+      Width no more than 217, and 214 is that with the same few pixels of slack the previous number kept.
 
-      The first number here was 248, from the same reasoning with the two margins left out. It laid out
+      Every number here has moved at least once, and always because something beside the cards did:
-      cleanly and the layout harness passed it, because the harness asks whether a control is inside the
+
-      window and not how many of them fit on a line — so the grid quietly became one column wide at exactly
+      · 248, from this reasoning with the two margins left out. It laid out cleanly and the layout harness
-      the size this application guarantees, which is the shape the cards exist to avoid. The second was 232,
+        passed it, because the harness asks whether a control is inside the window and not how many of them
-      derived the same way against the drawer's own 304; v5 widened the drawer to 320 for the ADDRESS field's
+        fit on a line — so the grid quietly became one column wide at exactly the size this application
-      breathing room, which narrowed the budget this number is drawn from and had to move it down in step.
+        guarantees, which is the shape the cards exist to avoid.
+      · 232, derived against the drawer's own 304, which v5 widened to 320 for the ADDRESS field's breathing
+        room — narrowing the budget this number is drawn from and moving it down in step.
+      · 224, which is what that gave. The stated arithmetic still said 1016 and 190 by then: v5b's rail took
+        190 to 255 and the window's minimum 1016 to 1081 in the same pass, so the two changes cancelled and
+        the answer stayed right while the working went stale.
+      · 214, now that HostsScreen's board is inset 26 a side rather than 16 — see that file's own remark on
+        why every screen frames its content the same way. Twenty pixels of board is twenty pixels the cards
+        no longer have, and this is where they come from.
+
+      ◆ THE TEST THAT CATCHES THIS IS NOT THE HARNESS. See
+      ScreenLayoutTests.TheHostsGridKeepsTwoColumnsAtTheMinimumWithTheDrawerOpen, which counts columns
+      because that is the thing this number exists to buy and the thing no fit assertion can see.
     -->
     <Style Selector="Border.tile">
       <Setter Property="Background" Value="{StaticResource Raised}" />
@@ -876,7 +944,7 @@
       <Setter Property="BorderThickness" Value="1" />
       <Setter Property="CornerRadius" Value="12" />
       <Setter Property="Padding" Value="12,10" />
-      <Setter Property="Width" Value="224" />
+      <Setter Property="Width" Value="214" />
       <Setter Property="Margin" Value="0,0,10,10" />
     </Style>
     <Style Selector="ListBoxItem:pointerover Border.tile">

src/DodoSSH.Client.App/Views/HostsScreen.axaml

@@ -98,6 +98,18 @@
 
   <Grid ColumnDefinitions="*,Auto">
 
+    <!--
+      ── 26 DOWN EACH SIDE, the same inset Keychain, Snips, Logs and Pins all take. ──────────────────────
+      Those four say it once, as Margin="26" on their own root; this screen repeats it on each of the four
+      rows below, and it has to. The board's ScrollViewer is the last row and is deliberately full-bleed, so
+      that its scrollbar rides the pane's own edge rather than floating 26 pixels inside it — a root margin
+      would inset the bar with everything else. It would also inset the drawer in the second column, which
+      draws its own edge and wants none.
+
+      It was 16 and 20 until this pass, which put the Hosts header a visible step left of and above every
+      other screen's. Four numbers rather than one is the cost of the two exceptions above; changing one of
+      them means changing all four.
+    -->
     <Grid Grid.Column="0" RowDefinitions="Auto,Auto,Auto,*">
 
       <!--
@@ -107,7 +119,7 @@
         buttons over a board of forty is a pair whose subject the user has to work out. The group's own
         Edit/Move/Delete sit on its own heading's menu for the same reason.
       -->
-      <Grid Grid.Row="0" Margin="16,20,16,16" ColumnDefinitions="Auto,Auto,*,Auto,Auto,Auto">
+      <Grid Grid.Row="0" Margin="26,26,26,16" ColumnDefinitions="Auto,Auto,*,Auto,Auto,Auto">
 
         <TextBlock Grid.Column="0" Text="Hosts" FontSize="33" FontWeight="Bold" LetterSpacing="-0.5"
                    Foreground="{StaticResource Text}" VerticalAlignment="Center" />
@@ -219,7 +231,7 @@
         Ctrl+K is named on it because the palette is the other way to reach a host by typing, and somebody
         who has found this box should know about the one that also connects on Enter.
       -->
-      <Border Grid.Row="1" Margin="16,0,16,16">
+      <Border Grid.Row="1" Margin="26,0,26,16">
         <TextBox x:Name="HostFilter" Text="{Binding HostFilter}" Height="40" CornerRadius="10"
                  FontFamily="{StaticResource MonoFont}"
                  PlaceholderText="Find a host by name, address or note…   ·   Ctrl+K searches and connects" />
@@ -232,7 +244,7 @@
         one of them sits here, above the board, rather than laid over it: a card over the cards would hide
         the very ticks or the very group it is asking about.
       -->
-      <StackPanel Grid.Row="2" Margin="16,0,16,12" Spacing="10">
+      <StackPanel Grid.Row="2" Margin="26,0,26,12" Spacing="10">
 
         <!--
           The conflict log. The merge is only allowed to pick a winner because the value it overrode is kept
@@ -434,7 +446,7 @@
         HostsScreen.axaml.cs.
       -->
       <ScrollViewer Grid.Row="3" x:Name="Scroll" HorizontalScrollBarVisibility="Disabled">
-        <StackPanel Margin="16,0,16,20" Spacing="16">
+        <StackPanel Margin="26,0,26,26" Spacing="16">
 
           <!--
             Named because it is where keyboard focus lands when the terminal gives it back, and because
@@ -690,7 +702,7 @@
                                   <Border Classes="chip" Height="19" CornerRadius="5" Padding="6,2"
                                           IsVisible="{Binding HasPins}">
                                     <StackPanel Orientation="Horizontal" Spacing="3">
-                                      <TextBlock Text="&#xE946;" FontFamily="{StaticResource IconFont}"
+                                      <TextBlock Text="&#xF10D;" FontFamily="{StaticResource IconFont}"
                                                  FontSize="11" Foreground="{StaticResource TextFaint}" />
                                       <TextBlock Classes="mono" Text="{Binding PinCount}" FontSize="10.5"
                                                  Foreground="{StaticResource TextFaint}" />

src/DodoSSH.Client.App/Views/MainWindow.axaml

@@ -148,13 +148,17 @@
                 <Border Grid.Row="1" BorderBrush="{StaticResource Border}" BorderThickness="1"
                         CornerRadius="0,0,12,12" ClipToBounds="True">
                   <Grid ColumnDefinitions="*,Auto">
-                    <Grid Grid.Column="0" RowDefinitions="Auto,*,Auto">
+                    <!--
-                      <views:SessionHeader Grid.Row="0"
+                      v5c-4: two rows rather than three. The 60-pixel host header that used to sit above this
-                                            OpenLabel="Open terminal"
+                      screen is gone; the address and the "Open terminal" button it carried are in the
-                                            OpenCommand="{Binding OpenTerminalForFilesHostCommand}"
+                      sidebar now — see SessionSidebar.axaml — and the pane keeps the height. Its third
-                                            EmptyText="{Binding Transfers.Status}" />
+                      binding, the Transfers.Status line it printed while no host was open, is not moved
-                      <views:TransfersScreen Grid.Row="1" DataContext="{Binding Transfers}" />
+                      either: TransfersScreen draws that same string itself, both in its own empty state and
-                      <views:SessionStatusBar Grid.Row="2" />
+                      beside the remote pane's DISCONNECT once something is open.
+                    -->
+                    <Grid Grid.Column="0" RowDefinitions="*,Auto">
+                      <views:TransfersScreen Grid.Row="0" DataContext="{Binding Transfers}" />
+                      <views:SessionStatusBar Grid.Row="1" />
                     </Grid>
                     <!--
                       Hides when no session is active — see ShowsQuickAccessSidebar — rather than always
@@ -268,14 +272,16 @@
             <Border Grid.Row="1" BorderBrush="{StaticResource Border}" BorderThickness="1"
                     CornerRadius="0,0,12,12" ClipToBounds="True">
               <Grid ColumnDefinitions="*,Auto">
-                <Grid Grid.Column="0" RowDefinitions="Auto,*,Auto">
+                <!--
-                  <views:SessionHeader Grid.Row="0"
+                  v5c-4: two rows rather than three, the same as the SFTP wrapper above and for the same
-                                        OpenLabel="Open SFTP"
+                  reason — the host header is gone and the terminal has its 60 pixels. The empty state it
-                                        OpenCommand="{Binding SelectFilesHostCommand}"
+                  used to print ("no terminals open · press + or Ctrl+K…") went with it rather than moving:
-                                        OpenCommandParameter="{Binding SelectedTab}"
+                  this Grid is only drawn on the terminal surface, and the surface with no tab open already
-                                        EmptyText="no terminals open · press + or Ctrl+K, or choose a host and press Connect" />
+                  answers for itself in the tab row's own "+" and in the connecting card below.
+                -->
+                <Grid Grid.Column="0" RowDefinitions="*,Auto">
 
-                  <Panel Grid.Row="1" Background="{StaticResource Pane}">
+                  <Panel Grid.Row="0" Background="{StaticResource Pane}">
 
                     <!--
                       The other thing that can be in the terminal's rectangle: a tab whose session does not
@@ -300,7 +306,7 @@
 
                   </Panel>
 
-                  <views:SessionStatusBar Grid.Row="2" ShowsEncoding="True" />
+                  <views:SessionStatusBar Grid.Row="1" ShowsEncoding="True" />
                 </Grid>
                 <!--
                   Hides when no session is active — see ShowsQuickAccessSidebar — rather than always drawn:

src/DodoSSH.Client.App/Views/MainWindow.axaml.cs

@@ -54,6 +54,21 @@ internal sealed partial class MainWindow : Window
         };
     }
 
+    /// <summary>
+    /// Colours the system-drawn frame the moment there is a handle to colour it on.
+    /// </summary>
+    /// <remarks>
+    /// <c>OnOpened</c> and not the constructor: the window has no platform handle until it is shown, and
+    /// <see cref="NativeWindowFrame"/> does nothing without one. See that class for what the frame is and
+    /// why <c>BorderOnly</c> still has one.
+    /// </remarks>
+    protected override void OnOpened(EventArgs e)
+    {
+        base.OnOpened(e);
+
+        NativeWindowFrame.MatchTo(this);
+    }
+
     /// <summary>
     /// Asks the Linux backend for the one mode it can actually draw inside this window.
     /// </summary>
@@ -268,6 +283,7 @@ internal sealed partial class MainWindow : Window
         if (shell is { } previous)
         {
             previous.TerminalSessionOpened -= OnTerminalSessionOpened;
+            previous.TerminalFocusRequested -= OnTerminalFocusRequested;
             previous.PropertyChanged -= OnShellPropertyChanged;
         }
 
@@ -286,6 +302,7 @@ internal sealed partial class MainWindow : Window
         wasUnlocked = viewModel.IsUnlocked;
 
         viewModel.TerminalSessionOpened += OnTerminalSessionOpened;
+        viewModel.TerminalFocusRequested += OnTerminalFocusRequested;
         viewModel.PropertyChanged += OnShellPropertyChanged;
     }
 
@@ -298,6 +315,15 @@ internal sealed partial class MainWindow : Window
     /// </remarks>
     private void OnTerminalSessionOpened(object? sender, EventArgs e) => FocusTerminalWhenLaidOut();
 
+    /// <remarks>
+    /// The same call for a session that was already open and has just been typed into from the sidebar —
+    /// see <see cref="MainWindowViewModel.TerminalFocusRequested"/>. Posted like every other path here,
+    /// although nothing was revealed this turn: the post also re-checks that a terminal is still showing,
+    /// which is what keeps this from stealing the keyboard if the insert landed the user on the snippets
+    /// screen instead.
+    /// </remarks>
+    private void OnTerminalFocusRequested(object? sender, EventArgs e) => FocusTerminalWhenLaidOut();
+
     /// <remarks>
     /// A dispatch and nothing else. Every arm below is a separate decision about where the keyboard goes,
     /// and they were one method until the four of them stopped fitting in a screenful — which is roughly the

src/DodoSSH.Client.App/Views/NativeWindowFrame.cs

@@ -0,0 +1,133 @@
+using System.Runtime.InteropServices;
+using Avalonia.Controls;
+using Avalonia.Media;
+
+namespace DodoSSH.Client.App.Views;
+
+/// <summary>
+/// Paints the frame Windows still draws around a <c>BorderOnly</c> window in the application's own
+/// colour, so the top edge stops reading as a leftover system titlebar.
+/// </summary>
+/// <remarks>
+/// <para>
+/// <b>The symptom this exists for:</b> a pale strip across the very top of the window, a few pixels
+/// tall and plainly not part of the application — most obvious on a machine with "show accent colour
+/// on title bars and window borders" turned on, where it comes out blue against a near-black shell.
+/// </para>
+/// <para>
+/// It is not <c>TitleBar.axaml</c> leaking and it is not a margin. It is DWM, and the reason it is
+/// there is visible in Avalonia's own Win32 backend: <c>WindowImpl.UpdateWindowProperties</c> gives a
+/// <see cref="WindowDecorations.BorderOnly"/> window <c>WS_BORDER | WS_THICKFRAME</c> and then calls
+/// <c>DwmExtendFrameIntoClientArea</c> with one-pixel margins on all four sides. So the compositor
+/// owns a hairline of every edge of this window, and it fills that hairline with the system's caption
+/// and border colours — which are chosen by the user's personalisation settings and have no reason to
+/// resemble <c>CanvasColor</c>. The window is the wrong place to look for the pixels; they were never
+/// painted by anything in this tree.
+/// </para>
+/// <para>
+/// The fix is to tell DWM what colour to use rather than to try to cover it. <c>DWMWA_BORDER_COLOR</c>
+/// and <c>DWMWA_CAPTION_COLOR</c> arrived in Windows 11 21H2 and are exactly that; both are set to the
+/// window's own background, so the hairline still exists — the resize grip is on it, and the drop
+/// shadow hangs off it — and simply cannot be seen. Deliberately <em>not</em> <c>DWMWA_COLOR_NONE</c>,
+/// which removes the border outright: on a dark desktop that leaves a near-black window with no edge
+/// at all, which trades one visual defect for another.
+/// </para>
+/// <para>
+/// Windows 10 gets the dark-mode attribute and nothing else, and that is the whole of what is
+/// available there: the two colour attributes are unsupported, <c>DwmSetWindowAttribute</c> answers
+/// <c>E_INVALIDARG</c>, and the calls do nothing. Hence the ignored return values — every attribute
+/// here is an improvement where it lands and a no-op where it does not, so there is nothing for a
+/// caller to handle and nothing worth logging on a path that runs once at startup.
+/// </para>
+/// </remarks>
+internal static class NativeWindowFrame
+{
+    /// <summary>Windows 11 21H2 and later: the colour of the frame border.</summary>
+    private const int BorderColorAttribute = 34;
+
+    /// <summary>Windows 11 21H2 and later: the colour of the caption, including the extended frame.</summary>
+    private const int CaptionColorAttribute = 35;
+
+    /// <summary>
+    /// Windows 10 1903 and later: draw the frame in the dark palette.
+    /// </summary>
+    /// <remarks>
+    /// Redundant on Windows 11, where the two colour attributes above name the colours outright, and it
+    /// is set anyway because it is the only one of the three that Windows 10 honours. The build before
+    /// 1903 used attribute 19 for this; that is not chased here, because a border on an OS release that
+    /// left support in 2020 is not worth a second interop call.
+    /// </remarks>
+    private const int DarkModeAttribute = 20;
+
+    /// <summary>
+    /// Matches <paramref name="window"/>'s system-drawn frame to the colour it paints itself.
+    /// </summary>
+    /// <remarks>
+    /// Call once the window has a handle — <c>OnOpened</c> is the first such moment. Calling earlier
+    /// finds no platform handle and silently does nothing, which is the defect this replaced: the strip
+    /// is only visible once the window is on screen, so a call that ran too early looks like a fix that
+    /// does not work rather than a fix that never ran.
+    /// </remarks>
+    internal static void MatchTo(Window window)
+    {
+        // Every attribute below is a DWM one, and DWM is Windows. Elsewhere the frame is drawn by the
+        // platform's own compositor and there is nothing here to say to it.
+        if (!OperatingSystem.IsWindows())
+        {
+            return;
+        }
+
+        if (window.TryGetPlatformHandle()?.Handle is not { } handle || handle == IntPtr.Zero)
+        {
+            return;
+        }
+
+        Set(handle, DarkModeAttribute, 1);
+
+        // The window's own Background rather than a named resource, so the frame cannot drift from the
+        // canvas when the palette moves. A brush that is not solid — a gradient, or nothing set at all —
+        // has no single colour to match, and leaving the system's own is better than inventing one.
+        if (window.Background is not ISolidColorBrush { Color: var canvas })
+        {
+            return;
+        }
+
+        var reference = ColorRef(canvas);
+        Set(handle, BorderColorAttribute, reference);
+        Set(handle, CaptionColorAttribute, reference);
+    }
+
+    /// <summary>
+    /// Sets one integer-valued DWM attribute, and discards the answer.
+    /// </summary>
+    /// <remarks>
+    /// The discard is the point of this method existing rather than being three call sites. Every
+    /// attribute here is unsupported on some Windows this application runs on, and unsupported means
+    /// <c>E_INVALIDARG</c> and no change — which is the intended outcome on that OS, not a failure, so
+    /// there is nothing for the caller to do with the <c>HRESULT</c> and nothing worth logging once at
+    /// startup. Written once, with the reasoning, rather than left implicit at each call.
+    /// </remarks>
+    private static void Set(IntPtr window, int attribute, int value) =>
+        _ = DwmSetWindowAttribute(window, attribute, ref value, sizeof(int));
+
+    /// <summary>
+    /// Packs <paramref name="color"/> into a Win32 <c>COLORREF</c>.
+    /// </summary>
+    /// <remarks>
+    /// <c>0x00BBGGRR</c> — blue in the high byte, not red, and the alpha byte must be zero. Getting the
+    /// order wrong produces a plausible-looking wrong colour rather than an error, which is the kind of
+    /// bug that survives a glance at the window.
+    /// </remarks>
+    private static int ColorRef(Color color) => color.R | (color.G << 8) | (color.B << 16);
+
+    /// <remarks>
+    /// <c>DllImport</c> rather than <c>LibraryImport</c>, for the reason
+    /// <see cref="NativeKeyboardFocus"/> gives at its own P/Invoke: the generated form needs
+    /// <c>AllowUnsafeBlocks</c> across a project that handles key material, and this signature is
+    /// blittable, so there is no marshalling for it to improve.
+    /// </remarks>
+#pragma warning disable SYSLIB1054
+    [DllImport("dwmapi.dll")]
+    private static extern int DwmSetWindowAttribute(IntPtr window, int attribute, ref int value, int size);
+#pragma warning restore SYSLIB1054
+}

src/DodoSSH.Client.App/Views/NavRail.axaml

@@ -40,8 +40,9 @@
     Both are still one click away; see the popover below the user chip. The chip itself carries the signed-
     in identity this application actually has — a display name and, where the server sent one, an email —
     which is also new: the titlebar drew an account name and a vault chip before this pass and does not any
-    more. See TitleBar.axaml and design-notes/v5b-fidelity-notes.md for the deviations this rail keeps on
+    more. See TitleBar.axaml and design-notes/v5b-fidelity-notes.md for the one deviation this rail still
-    purpose: Pins, which the mock has no screen for at all, and the S3 segment above.
+    keeps on purpose: the S3 segment above. Pins was the other, and it is gone — see the remark where that
+    row used to sit, between Keys and Snips.
 
     Buttons rather than a TabStrip or a ListBox, still, for the reason the v3 remark gave: all three hold
     the selection themselves, so a click would move the highlight before the shell decided anything, and a
@@ -128,19 +129,16 @@
           </Button>
 
           <!--
-            KEPT — the mock has no screen for approved host keys at all; see the file-level remark. push_pin
+            ◆ NO Pins ROW. The pins screen is still here and still reached in one click — from "Host keys"
-            is the same codepoint HostsScreen.axaml already draws for a host's own pin badge, reused rather
+            on the Keys screen's own header, which is where a list of approved host keys belongs: they are
-            than picked afresh so the one concept reads as one glyph everywhere it appears.
+            keychain material, and that button was already the second way to reach them. Two rail rows away
+            from each other, both landing on the same screen, is a rail that has to be read twice.
+
+            It is also the last of the rail's own deviations from the mock to go. The row was kept in v5b on
+            the grounds that the design has no screen for approved host keys at all — see the file-level
+            remark — which is true of the design and was never a reason for a rail entry once the keychain
+            had a door to the same place.
           -->
-          <Button Classes="flat nav" Classes.active="{Binding IsKnownHostsShowing}"
-                  Command="{Binding ShowScreenCommand}"
-                  CommandParameter="{x:Static vm:ShellScreen.KnownHosts}"
-                  ToolTip.Tip="Host keys you have approved, and how to withdraw one">
-            <StackPanel Orientation="Horizontal" Spacing="10">
-              <TextBlock Classes="navicon" Text="&#xE946;" />
-              <TextBlock Classes="navlabel" Text="Pins" />
-            </StackPanel>
-          </Button>
 
           <Button Classes="flat nav" Classes.active="{Binding IsSnippetsShowing}"
                   Command="{Binding ShowScreenCommand}"
@@ -191,17 +189,22 @@
         </Grid>
 
         <FlyoutBase.AttachedFlyout>
-          <Flyout Placement="TopEdgeAlignedLeft">
+          <!--
-            <StackPanel Width="227" Spacing="8">
+            FlyoutPresenterClasses, because a Flyout's own panel is not in this markup's visual tree to be
+            styled from here — see FlyoutPresenter.poppanel in App.axaml for what the class carries and why
+            the shared popup rule was not simply widened to cover it.
+          -->
+          <Flyout Placement="TopEdgeAlignedLeft" FlyoutPresenterClasses="poppanel">
+            <StackPanel Width="227" Spacing="4">
 
               <!--
                 The real email, when the server sent one — verified against MainWindowViewModel.Email rather
                 than assumed, and simply absent from the popover when it has not. No " · Org" suffix: there
                 is no organisation concept behind a vault, only the vault itself, which the rows below name.
               -->
-              <TextBlock FontSize="10.5" FontWeight="Medium" LetterSpacing="0.1"
+              <TextBlock FontSize="10.5" FontWeight="Medium" LetterSpacing="0.1" Margin="11,4,11,6"
                          Foreground="{StaticResource TextGhost}"
-                         Text="{Binding Email}"
+                         Text="{Binding Email}" TextTrimming="CharacterEllipsis"
                          IsVisible="{Binding Email, Converter={x:Static StringConverters.IsNotNullOrEmpty}}" />
 
               <!--
@@ -246,7 +249,7 @@
                 </Grid>
               </Button>
 
-              <Border Height="1" Background="{StaticResource BorderMid}" />
+              <Border Height="1" Margin="11,4" Background="{StaticResource BorderMid}" />
 
               <!--
                 v5c: Settings, Vaults and Preferences now each land on their own page of the settings mode —
@@ -260,16 +263,23 @@
               <Button Classes="poprow" Click="OnPopoverSettingsPressed">
                 <StackPanel Orientation="Horizontal" Spacing="10">
                   <TextBlock FontFamily="{StaticResource IconFont}" Text="&#xE8B8;" FontSize="12"
-                             Foreground="{StaticResource Text}" />
+                             Foreground="{StaticResource TextGhost}" />
                   <TextBlock Text="Settings" FontSize="10" Foreground="{StaticResource Text}" />
                 </StackPanel>
               </Button>
 
+              <!--
+                ◆ THE SAME TREATMENT AS SETTINGS ABOVE AND LOGOUT BELOW, which these two did not have: their
+                label was TextGhost where the other two rows' was Text, so a menu of five equally live
+                destinations drew two of them in the colour this window uses for something switched off. The
+                icons stay one step quieter than the words — the idiom the nav rail's own rows already follow
+                — but "quieter than the word beside it" and "dimmed" are not the same statement.
+              -->
               <Button Classes="poprow" Click="OnPopoverVaultsPressed">
                 <StackPanel Orientation="Horizontal" Spacing="10">
                   <TextBlock FontFamily="{StaticResource IconFont}" Text="&#xE84F;" FontSize="12"
                              Foreground="{StaticResource TextGhost}" />
-                  <TextBlock Text="Vaults" FontSize="10" Foreground="{StaticResource TextGhost}" />
+                  <TextBlock Text="Vaults" FontSize="10" Foreground="{StaticResource Text}" />
                 </StackPanel>
               </Button>
 
@@ -277,11 +287,11 @@
                 <StackPanel Orientation="Horizontal" Spacing="10">
                   <TextBlock FontFamily="{StaticResource IconFont}" Text="&#xE429;" FontSize="12"
                              Foreground="{StaticResource TextGhost}" />
-                  <TextBlock Text="Preferences" FontSize="10" Foreground="{StaticResource TextGhost}" />
+                  <TextBlock Text="Preferences" FontSize="10" Foreground="{StaticResource Text}" />
                 </StackPanel>
               </Button>
 
-              <Border Height="1" Background="{StaticResource BorderMid}" />
+              <Border Height="1" Margin="11,4" Background="{StaticResource BorderMid}" />
 
               <!--
                 The existing sign-out flow, with its own confirm card — see
@@ -291,7 +301,7 @@
               <Button Classes="poprow" Click="OnPopoverLogoutPressed">
                 <StackPanel Orientation="Horizontal" Spacing="10">
                   <TextBlock FontFamily="{StaticResource IconFont}" Text="&#xE9BA;" FontSize="12"
-                             Foreground="{StaticResource Text}" />
+                             Foreground="{StaticResource TextGhost}" />
                   <TextBlock Text="Logout" FontSize="10" Foreground="{StaticResource Text}" />
                 </StackPanel>
               </Button>

src/DodoSSH.Client.App/Views/SessionHeader.axaml

@@ -1,49 +0,0 @@
-<UserControl xmlns="https://github.com/avaloniaui"
-             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
-             xmlns:vm="using:DodoSSH.Client.Shell.ViewModels"
-             x:Class="DodoSSH.Client.App.Views.SessionHeader"
-             x:Name="Root"
-             x:DataType="vm:MainWindowViewModel">
-
-  <!--
-    ── v5b's session shell host header ──────────────────────────────────────────────────────────────────────
-    60px, DeepChrome, atop the pane both the terminal and the SFTP surface hold. Per the design, minus the
-    three deviations design-notes/v5b-fidelity-notes.md records: no OS label, no latency reading, no "Port
-    forward" button — none of those are facts this application has.
-
-    ◆ THE ONE FACT LEFT is the address, read off MainWindowViewModel.SessionAddress — which is already the
-    surface-aware property, so this control asks no question about which screen it is on. What differs
-    between the two usages is only the cross-surface button: <see cref="OpenLabel"/>, <see cref="OpenCommand"/>
-    and the empty-state copy, all handed in from MainWindow.axaml rather than branched on here.
-  -->
-
-  <Border Height="60" Background="{StaticResource DeepChrome}"
-          BorderBrush="{StaticResource Border}" BorderThickness="0,0,0,1">
-    <Grid ColumnDefinitions="*,Auto" Margin="24,0,20,0">
-
-      <!--
-        The address, only while a session/host context is active — see SessionAddress's own remark for what
-        "active" means on each surface. The empty state takes its place otherwise, in the idiom every other
-        screen's own "nothing yet" sentence already uses: TextFaint, sentence case, no punctuation implying a
-        form to fill in.
-      -->
-      <TextBlock Grid.Column="0" FontFamily="{StaticResource MonoFont}" FontWeight="Bold" FontSize="14"
-                 Foreground="{StaticResource AccentText}" VerticalAlignment="Center"
-                 Text="{Binding SessionAddress}" ToolTip.Tip="{Binding SessionAddress}"
-                 TextTrimming="CharacterEllipsis"
-                 IsVisible="{Binding SessionAddress, Converter={x:Static StringConverters.IsNotNullOrEmpty}}" />
-
-      <TextBlock Grid.Column="0" Classes="mono" FontSize="12.5"
-                 Foreground="{StaticResource TextFaint}" VerticalAlignment="Center"
-                 Text="{Binding #Root.EmptyText}" TextTrimming="CharacterEllipsis"
-                 IsVisible="{Binding SessionAddress, Converter={x:Static StringConverters.IsNullOrEmpty}}" />
-
-      <Button Grid.Column="1" Classes="headerghost"
-              Content="{Binding #Root.OpenLabel}"
-              Command="{Binding #Root.OpenCommand}"
-              CommandParameter="{Binding #Root.OpenCommandParameter}" />
-
-    </Grid>
-  </Border>
-
-</UserControl>

src/DodoSSH.Client.App/Views/SessionHeader.axaml.cs

@@ -1,58 +0,0 @@
-using System.Windows.Input;
-using Avalonia;
-using Avalonia.Controls;
-
-namespace DodoSSH.Client.App.Views;
-
-/// <summary>
-/// The v5b session shell's host header: the address, and a ghost button that crosses to the other surface.
-/// See the remark at the top of SessionHeader.axaml.
-/// </summary>
-internal sealed partial class SessionHeader : UserControl
-{
-    /// <summary>What the cross-surface ghost button says — "Open SFTP" or "Open terminal".</summary>
-    internal static readonly StyledProperty<string?> OpenLabelProperty =
-        AvaloniaProperty.Register<SessionHeader, string?>(nameof(OpenLabel));
-
-    /// <summary>What the cross-surface ghost button runs.</summary>
-    /// <remarks>
-    /// The terminal usage binds <c>SelectFilesHostCommand</c> with the selected tab as its parameter; the
-    /// SFTP usage binds <c>OpenTerminalForFilesHostCommand</c>, which needs none — see the remark on both in
-    /// <c>MainWindowViewModel</c> for why the two directions are not symmetrical.
-    /// </remarks>
-    internal static readonly StyledProperty<ICommand?> OpenCommandProperty =
-        AvaloniaProperty.Register<SessionHeader, ICommand?>(nameof(OpenCommand));
-
-    internal static readonly StyledProperty<object?> OpenCommandParameterProperty =
-        AvaloniaProperty.Register<SessionHeader, object?>(nameof(OpenCommandParameter));
-
-    /// <summary>What the header says instead of an address, while no session/host context is active.</summary>
-    internal static readonly StyledProperty<string?> EmptyTextProperty =
-        AvaloniaProperty.Register<SessionHeader, string?>(nameof(EmptyText));
-
-    public SessionHeader() => InitializeComponent();
-
-    internal string? OpenLabel
-    {
-        get => GetValue(OpenLabelProperty);
-        set => SetValue(OpenLabelProperty, value);
-    }
-
-    internal ICommand? OpenCommand
-    {
-        get => GetValue(OpenCommandProperty);
-        set => SetValue(OpenCommandProperty, value);
-    }
-
-    internal object? OpenCommandParameter
-    {
-        get => GetValue(OpenCommandParameterProperty);
-        set => SetValue(OpenCommandParameterProperty, value);
-    }
-
-    internal string? EmptyText
-    {
-        get => GetValue(EmptyTextProperty);
-        set => SetValue(EmptyTextProperty, value);
-    }
-}

src/DodoSSH.Client.App/Views/SessionSidebar.axaml

@@ -19,70 +19,100 @@
     Every row here is a command the shell already exposes for exactly this purpose — see
     MainWindowViewModel.PinFolderFromSidebarCommand, AddSnippetFromSidebarCommand and InsertSnippetCommand —
     so this control carries no logic of its own beyond the list it draws and the click it forwards.
+
+    ── v5c-4: THE SESSION BLOCK AT THE HEAD, AND THE HEADER ROW THAT IS GONE ─────────────────────────────────
+    The 60-pixel host header that used to sit above the pane on both surfaces has been retired, and its two
+    contents moved up here: the address it printed, and the cross-surface button — "Open SFTP" from a
+    terminal, "Open terminal" from SFTP. Which of the two words it is and which command it runs are resolved
+    by the shell now rather than handed in from the two usage sites; see
+    MainWindowViewModel.SessionCrossSurfaceLabel and OpenOtherSurfaceCommand. The pane keeps that height.
+
+    The address is the fact the header row existed for, so it moves rather than disappears. It sits where the
+    QUICK ACCESS heading used to print the selected tab's short label — that label said less than the address
+    does and would be the same word twice beside it.
+
+    ── AND THE COLUMN CLOSES ────────────────────────────────────────────────────────────────────────────────
+    300 pixels is a lot of a 1180-pixel window to give a list that is often two rows long, so the column
+    folds to a 34-pixel rail carrying the way back. A rail rather than nothing: a panel that vanishes without
+    trace is one people report as lost. Both halves live in this control and swap on
+    MainWindowViewModel.IsSessionSidebarOpen, so MainWindow.axaml's own "Auto" column takes whichever width
+    is showing without knowing anything about the state — and the pane beside it grows into what is freed.
   -->
 
-  <Border Width="300" Background="{StaticResource Sidebar}"
+  <Panel>
-          BorderBrush="{StaticResource Border}" BorderThickness="1,0,0,0">
-    <ScrollViewer VerticalScrollBarVisibility="Auto">
-      <StackPanel Spacing="6" Margin="16,20">
 
-        <!-- ============ QUICK ACCESS ============ -->
+    <!-- ============ THE RAIL, WHEN THE COLUMN IS CLOSED ============ -->
-        <Grid ColumnDefinitions="*,Auto" Margin="8,0">
+    <!--
-          <TextBlock Grid.Column="0" Classes="label" Text="QUICK ACCESS" FontSize="10" />
+      Painted and bordered like the open column so the closing reads as the same surface narrowing rather
-          <TextBlock Grid.Column="1" Classes="mono" FontSize="10"
+      than as one piece of furniture being swapped for another.
-                     Foreground="{StaticResource TextGhost}"
+    -->
-                     Text="{Binding SelectedTab.Label}" TextTrimming="CharacterEllipsis" MaxWidth="130" />
+    <Border Width="34" Background="{StaticResource Sidebar}"
-        </Grid>
+            BorderBrush="{StaticResource Border}" BorderThickness="1,0,0,0"
+            IsVisible="{Binding !IsSessionSidebarOpen}">
+      <Button Classes="flat sidebargrip" VerticalAlignment="Top" Margin="0,20,0,0"
+              Command="{Binding ToggleSessionSidebarCommand}"
+              ToolTip.Tip="Show quick access, snips and the way across to the other surface">
+        <TextBlock Text="&#xE5CB;" FontFamily="{StaticResource IconFont}" FontSize="18"
+                   Foreground="{StaticResource TextFaint}"
+                   HorizontalAlignment="Center" VerticalAlignment="Center" />
+      </Button>
+    </Border>
 
-        <ItemsControl ItemsSource="{Binding ActiveTabPinnedPaths}">
+    <!-- ============ THE COLUMN ============ -->
-          <ItemsControl.ItemTemplate>
+    <Border Width="300" Background="{StaticResource Sidebar}"
-            <DataTemplate x:DataType="x:String">
+            BorderBrush="{StaticResource Border}" BorderThickness="1,0,0,0"
-              <!--
+            IsVisible="{Binding IsSessionSidebarOpen}">
-                A single level of $parent[ItemsControl] reaches the shell directly, the same way the old pin
+      <ScrollViewer VerticalScrollBarVisibility="Auto">
-                strip's chips did: this ItemsControl's own DataContext is MainWindowViewModel, so one hop up
+        <StackPanel Spacing="6" Margin="16,20">
-                from the path's string DataContext lands on it.
-              -->
-              <Button Classes="sidebarrow"
-                      Command="{Binding $parent[ItemsControl].((vm:MainWindowViewModel)DataContext).OpenPinnedPathCommand}"
-                      CommandParameter="{Binding}"
-                      ToolTip.Tip="{Binding}">
-                <StackPanel Orientation="Horizontal" Spacing="10">
-                  <TextBlock Text="&#xE2C7;" FontFamily="{StaticResource IconFont}" FontSize="15"
-                             Foreground="{StaticResource AccentText}" VerticalAlignment="Center" />
-                  <TextBlock FontFamily="{StaticResource MonoFont}" FontSize="12.5" Text="{Binding}"
-                             TextTrimming="CharacterEllipsis" VerticalAlignment="Center" />
-                </StackPanel>
-              </Button>
-            </DataTemplate>
-          </ItemsControl.ItemTemplate>
-        </ItemsControl>
 
-        <Button Classes="sidebaradd" Command="{Binding PinFolderFromSidebarCommand}"
+          <!-- ============ THE SESSION ============ -->
-                ToolTip.Tip="Opens the active tab's host for editing, at QUICK ACCESS.">
+          <!--
-          <StackPanel Orientation="Horizontal" Spacing="10">
+            The address, and the button that closes the column. Both on one row, and the address is the
-            <TextBlock Text="&#xE145;" FontFamily="{StaticResource IconFont}" FontSize="14"
+            trimming one: a long account@host:port is exactly the string that would otherwise push the
-                       VerticalAlignment="Center" />
+            close button off the edge of a panel whose whole point is that it can be got rid of.
-            <TextBlock Text="Pin folder" VerticalAlignment="Center" />
+          -->
-          </StackPanel>
+          <Grid ColumnDefinitions="*,Auto" Margin="8,0,0,0">
-        </Button>
+            <TextBlock Grid.Column="0" FontFamily="{StaticResource MonoFont}" FontWeight="Bold"
+                       FontSize="12.5" Foreground="{StaticResource AccentText}"
+                       VerticalAlignment="Center" TextTrimming="CharacterEllipsis"
+                       Text="{Binding SessionAddress}" ToolTip.Tip="{Binding SessionAddress}" />
+            <Button Grid.Column="1" Classes="flat sidebargrip"
+                    Command="{Binding ToggleSessionSidebarCommand}"
+                    ToolTip.Tip="Close this column. The terminal takes the width, and the rail it leaves behind brings it back.">
+              <TextBlock Text="&#xE5CC;" FontFamily="{StaticResource IconFont}" FontSize="18"
+                         Foreground="{StaticResource TextFaint}"
+                         HorizontalAlignment="Center" VerticalAlignment="Center" />
+            </Button>
+          </Grid>
 
-        <!-- ============ SNIPS (the terminal surface only) ============ -->
+          <!--
-        <StackPanel Spacing="6" Margin="0,16,0,0" IsVisible="{Binding #Root.ShowsSnips}">
+            The cross-surface button, stretched across the column rather than sized to its own caption: it
+            is the one action in this panel that is not a list row, and a 90-pixel button floating at the
+            left of a 300-pixel column would read as unfinished.
+          -->
+          <Button Classes="headerghost" HorizontalAlignment="Stretch" Margin="0,4,0,10"
+                  Content="{Binding SessionCrossSurfaceLabel}"
+                  Command="{Binding OpenOtherSurfaceCommand}" />
 
-          <TextBlock Classes="label" Text="SNIPS" FontSize="10" Margin="8,0" />
+          <!-- ============ QUICK ACCESS ============ -->
+          <TextBlock Classes="label" Text="QUICK ACCESS" FontSize="10" Margin="8,0" />
 
-          <ItemsControl ItemsSource="{Binding SnippetsScreen.Visible}">
+          <ItemsControl ItemsSource="{Binding ActiveTabPinnedPaths}">
             <ItemsControl.ItemTemplate>
-              <DataTemplate x:DataType="vm:SnippetRowViewModel">
+              <DataTemplate x:DataType="x:String">
+                <!--
+                  A single level of $parent[ItemsControl] reaches the shell directly, the same way the old pin
+                  strip's chips did: this ItemsControl's own DataContext is MainWindowViewModel, so one hop up
+                  from the path's string DataContext lands on it.
+                -->
                 <Button Classes="sidebarrow"
-                        Command="{Binding $parent[ItemsControl].((vm:MainWindowViewModel)DataContext).InsertSnippetCommand}"
+                        Command="{Binding $parent[ItemsControl].((vm:MainWindowViewModel)DataContext).OpenPinnedPathCommand}"
                         CommandParameter="{Binding}"
-                        ToolTip.Tip="{Binding Snippet.Command}">
+                        ToolTip.Tip="{Binding}">
                   <StackPanel Orientation="Horizontal" Spacing="10">
-                    <TextBlock Text="{}{ }" FontFamily="{StaticResource MonoFont}" FontWeight="Bold"
+                    <TextBlock Text="&#xE2C7;" FontFamily="{StaticResource IconFont}" FontSize="15"
-                               FontSize="11" Foreground="{StaticResource AccentText}"
+                               Foreground="{StaticResource AccentText}" VerticalAlignment="Center" />
-                               VerticalAlignment="Center" />
+                    <TextBlock FontFamily="{StaticResource MonoFont}" FontSize="12.5" Text="{Binding}"
-                    <TextBlock FontFamily="{StaticResource MonoFont}" FontSize="12.5" Text="{Binding Label}"
                                TextTrimming="CharacterEllipsis" VerticalAlignment="Center" />
                   </StackPanel>
                 </Button>
@@ -90,19 +120,54 @@
             </ItemsControl.ItemTemplate>
           </ItemsControl>
 
-          <Button Classes="sidebaradd" Command="{Binding AddSnippetFromSidebarCommand}"
+          <Button Classes="sidebaradd" Command="{Binding PinFolderFromSidebarCommand}"
-                  ToolTip.Tip="Opens the snippet editor.">
+                  ToolTip.Tip="Opens the active tab's host for editing, at QUICK ACCESS.">
             <StackPanel Orientation="Horizontal" Spacing="10">
               <TextBlock Text="&#xE145;" FontFamily="{StaticResource IconFont}" FontSize="14"
                          VerticalAlignment="Center" />
-              <TextBlock Text="Add Snip" VerticalAlignment="Center" />
+              <TextBlock Text="Pin folder" VerticalAlignment="Center" />
             </StackPanel>
           </Button>
 
-        </StackPanel>
+          <!-- ============ SNIPS (the terminal surface only) ============ -->
+          <StackPanel Spacing="6" Margin="0,16,0,0" IsVisible="{Binding #Root.ShowsSnips}">
 
-      </StackPanel>
+            <TextBlock Classes="label" Text="SNIPS" FontSize="10" Margin="8,0" />
-    </ScrollViewer>
+
-  </Border>
+            <ItemsControl ItemsSource="{Binding SnippetsScreen.Visible}">
+              <ItemsControl.ItemTemplate>
+                <DataTemplate x:DataType="vm:SnippetRowViewModel">
+                  <Button Classes="sidebarrow"
+                          Command="{Binding $parent[ItemsControl].((vm:MainWindowViewModel)DataContext).InsertSnippetCommand}"
+                          CommandParameter="{Binding}"
+                          ToolTip.Tip="{Binding Snippet.Command}">
+                    <StackPanel Orientation="Horizontal" Spacing="10">
+                      <TextBlock Text="{}{ }" FontFamily="{StaticResource MonoFont}" FontWeight="Bold"
+                                 FontSize="11" Foreground="{StaticResource AccentText}"
+                                 VerticalAlignment="Center" />
+                      <TextBlock FontFamily="{StaticResource MonoFont}" FontSize="12.5" Text="{Binding Label}"
+                                 TextTrimming="CharacterEllipsis" VerticalAlignment="Center" />
+                    </StackPanel>
+                  </Button>
+                </DataTemplate>
+              </ItemsControl.ItemTemplate>
+            </ItemsControl>
+
+            <Button Classes="sidebaradd" Command="{Binding AddSnippetFromSidebarCommand}"
+                    ToolTip.Tip="Opens the snippet editor.">
+              <StackPanel Orientation="Horizontal" Spacing="10">
+                <TextBlock Text="&#xE145;" FontFamily="{StaticResource IconFont}" FontSize="14"
+                           VerticalAlignment="Center" />
+                <TextBlock Text="Add Snip" VerticalAlignment="Center" />
+              </StackPanel>
+            </Button>
+
+          </StackPanel>
+
+        </StackPanel>
+      </ScrollViewer>
+    </Border>
+
+  </Panel>
 
 </UserControl>

src/DodoSSH.Client.App/Views/SettingsTitleBar.axaml

@@ -9,8 +9,8 @@
     the same 53px bar: "Back to application" on the left, in place of the wordmark and the search box, and
     the same three window-control glyphs on the right TitleBar.axaml already draws.
 
-    A separate control rather than a variant of TitleBar itself, on the same reasoning SessionHeader and
+    A separate control rather than a variant of TitleBar itself, on the same reasoning SessionStatusBar and
-    SessionStatusBar are their own files: nothing here can be measured by a test that hosts the real window,
+    SessionSidebar are their own files: nothing here can be measured by a test that hosts the real window,
     and a control that is either "the wordmark bar" or "the settings bar" depending on a bound flag would be
     two controls wearing one name. The dragging, maximising and closing logic is duplicated from TitleBar's
     own code-behind rather than shared through a base class — four short handlers, and the day one of the two

src/DodoSSH.Client.App/Views/TitleBar.axaml

@@ -79,8 +79,16 @@
             -->
             <TextBlock Grid.Column="1" Text="Search or connect…" FontSize="13.5" Margin="10,0"
                        Foreground="{StaticResource TextGhost}" VerticalAlignment="Center" />
-            <!-- CTRL K, not the design's ⌘K — see the remark at the top of this file. -->
+            <!--
-            <Border Grid.Column="2" Width="34" Height="18" CornerRadius="5"
+              CTRL K, not the design's ⌘K — see the remark at the top of this file.
+
+              ◆ PADDED RATHER THAN 34 WIDE, which is the design's own width for a chip reading ⌘K: two
+              glyphs, where the substitution this bar makes is six characters and a space. At 10.5 mono
+              that run is wider than 34, so the chip clipped it — "CTRL" with the K cut in half. MinWidth
+              keeps the design's footprint for the day this face has a ⌘ to draw, and the padding is what
+              the longer label actually needs.
+            -->
+            <Border Grid.Column="2" MinWidth="34" Height="18" CornerRadius="5" Padding="7,0"
                     Background="{StaticResource KbdChip}"
                     HorizontalAlignment="Center" VerticalAlignment="Center">
               <TextBlock Classes="mono" Text="CTRL K" FontSize="10.5" FontWeight="Medium"

src/DodoSSH.Client.App/Views/TransfersScreen.axaml

@@ -382,8 +382,9 @@
         <!--
           ◆ WHAT IS OPEN, AND WHAT CLOSES IT. Only while something is.
 
-          v5b drops the account-at-host chip this row used to carry beside DISCONNECT: SessionHeader now
+          v5b drops the account-at-host chip this row used to carry beside DISCONNECT: the session shell
-          prints the very same address above this whole screen — see MainWindowViewModel.SessionAddress,
+          prints the very same address beside this screen — in the sidebar's own session block since v5c-4
+          retired the header row that printed it above — see MainWindowViewModel.SessionAddress,
           which already reads Transfers.ConnectedTo on the SFTP surface — and repeating it here stopped being
           information and started being the thing squeezing DISCONNECT off the edge. At the session shell's
           own narrower budget this pane is 204 pixels wide once QUICK ACCESS is showing beside it, where the

src/DodoSSH.Client.Session/ClientSettings.cs

@@ -23,9 +23,13 @@ namespace DodoSSH.Client.Session;
 /// <param name="AutomaticUpdateChecks">
 /// Whether this machine looks for a newer build on its own. See the remarks on the property.
 /// </param>
+/// <param name="SessionSidebarOpen">
+/// Whether the session shell's QUICK ACCESS sidebar is drawn. See the remarks on the property.
+/// </param>
 public sealed record ClientSettings(
     int TerminalFontSize = ClientSettings.DefaultTerminalFontSize,
-    bool AutomaticUpdateChecks = true)
+    bool AutomaticUpdateChecks = true,
+    bool SessionSidebarOpen = true)
 {
     /*
       A positional record, and the defaults live on the parameters rather than on property initializers.
@@ -102,6 +106,24 @@ public sealed record ClientSettings(
       warns against.
     */
 
+    /*
+      SessionSidebarOpen: why closing the sidebar is remembered, and why it is remembered here.
+
+      On by default, because the sidebar is where a session's pins, its snips and the way across to the
+      other surface live — a first launch that hid all three would be hiding the feature rather than
+      offering to.
+
+      Remembered at all because closing it is a choice about how much of a 1180-pixel window a terminal
+      gets, and a choice that has to be made again on every launch is one the application is not really
+      offering. It belongs in this file rather than in the vault for the same reason the font size does:
+      it is a fact about this screen, not about this keychain, and following somebody from a 27-inch
+      monitor onto a laptop would be a preference nobody asked for.
+
+      Not per-surface and not per-tab. The sidebar is one control drawn on two screens — see
+      SessionSidebar.axaml — and a window where it is open on SFTP and closed on the terminal is a
+      window that appears to lose it at random.
+    */
+
     /// <summary>Brings a value inside the range this type will store.</summary>
     public static int ClampTerminalFontSize(int pixels) =>
         Math.Clamp(pixels, MinimumTerminalFontSize, MaximumTerminalFontSize);

src/DodoSSH.Client.Shell/ViewModels/MainWindowViewModel.cs

@@ -550,16 +550,30 @@ internal sealed partial class MainWindowViewModel : ObservableObject, IAsyncDisp
 
         updateScreen = CreateUpdateScreen(updates);
 
-        // Read straight away rather than at first use, so the value is right before anything can read it —
+        ApplyStoredPreferences();
-        // a phone draws its terminal buttons from this, and a size that arrived a moment later would show
-        // as the interface correcting itself.
-        TerminalFontSize = ClientSettings.ClampTerminalFontSize(settings.Read().TerminalFontSize);
 
         _ = TellRendererTheFontSizeAsync();
 
         StartSessionShellTracking();
     }
 
+    /// <summary>
+    /// Takes this machine's own preferences off disk, before anything can read them.
+    /// </summary>
+    /// <remarks>
+    /// Read straight away rather than at first use, and both of them for the same reason: whatever is stored
+    /// is what the first window draws. A phone builds its terminal's font buttons from the size, and the
+    /// session shell decides whether to give a sidebar 300 pixels — either arriving a moment later shows as
+    /// the interface correcting itself in front of the user.
+    /// </remarks>
+    private void ApplyStoredPreferences()
+    {
+        var stored = settings.Read();
+
+        TerminalFontSize = ClientSettings.ClampTerminalFontSize(stored.TerminalFontSize);
+        IsSessionSidebarOpen = stored.SessionSidebarOpen;
+    }
+
     /// <summary>
     /// Wires up the two pieces of v5b's session shell that this constructor had no room left to inline.
     /// </summary>
@@ -1003,6 +1017,20 @@ internal sealed partial class MainWindowViewModel : ObservableObject, IAsyncDisp
     /// </remarks>
     internal event EventHandler? TerminalSessionOpened;
 
+    /// <summary>
+    /// Raised when something this shell did belongs in the terminal the user is already looking at, so the
+    /// view can put the keyboard back there.
+    /// </summary>
+    /// <remarks>
+    /// Separate from <see cref="TerminalSessionOpened"/> because no session opened: the sidebar's SNIPS row
+    /// typed into one that was already running, and the click that did it moved Win32 focus onto an Avalonia
+    /// button. The page cannot fix that from its side — see the <c>term.focus()</c> at the end of
+    /// <c>terminal.js</c>'s paste handler, which only ever reaches <c>document.activeElement</c> — so the
+    /// half that can only be done by the host is asked for here. The view re-checks that a terminal is
+    /// actually showing before it acts; see <c>MainWindow.FocusTerminalWhenLaidOut</c>.
+    /// </remarks>
+    internal event EventHandler? TerminalFocusRequested;
+
     internal bool IsStarting => State == ShellState.Starting;
 
     internal bool IsNeedingServer => State == ShellState.NeedsServer;
@@ -3824,6 +3852,72 @@ internal sealed partial class MainWindowViewModel : ObservableObject, IAsyncDisp
         (IsTerminalSurface && SelectedTab is not null)
         || (IsTransfersShowing && Transfers.IsConnected);
 
+    /// <summary>
+    /// Whether the sidebar is drawn in full, as opposed to collapsed to the rail that brings it back.
+    /// </summary>
+    /// <remarks>
+    /// A separate question from <see cref="ShowsQuickAccessSidebar"/>, and the two are not interchangeable:
+    /// that one is "is there a session for this to be about", which the shell answers, and this one is "does
+    /// the person want to see it", which only they can. Closed still draws something — a 34-pixel rail with
+    /// the way back on it; see <c>SessionSidebar.axaml</c> — because a panel that vanishes with no trace of
+    /// how to get it back is one people report as lost rather than as closed. Remembered between launches;
+    /// see <see cref="ToggleSessionSidebar"/> and <c>ClientSettings.SessionSidebarOpen</c>.
+    /// </remarks>
+    [ObservableProperty]
+    private bool isSessionSidebarOpen = true;
+
+    /// <summary>Opens the session sidebar, or closes it to its rail.</summary>
+    /// <remarks>
+    /// Written through on every toggle rather than on shutdown: this shell is disposed on paths that do not
+    /// all run to completion — a killed process, a phone's activity going away — and a preference that
+    /// survives only a clean exit is one that will sometimes be forgotten for no reason the user can see.
+    /// The store swallows its own failures and says whether it wrote; nothing here can do anything useful
+    /// with the answer, so the toggle stands whether or not the disk took it.
+    /// </remarks>
+    [RelayCommand]
+    private void ToggleSessionSidebar()
+    {
+        IsSessionSidebarOpen = !IsSessionSidebarOpen;
+
+        _ = settings.Write(settings.Read() with { SessionSidebarOpen = IsSessionSidebarOpen });
+    }
+
+    /// <summary>
+    /// The label on the sidebar's cross-surface row: where the other half of this host is.
+    /// </summary>
+    /// <remarks>
+    /// v5c-4 moved this button off the session shell's own 60-pixel header row and into the sidebar, and the
+    /// header went with it — see <c>SessionSidebar.axaml</c>. What the two surfaces hand in separately used
+    /// to be a pair of properties on the header control; it is resolved here now, for the same reason
+    /// <see cref="SessionAddress"/> is: the sidebar is one control drawn on both surfaces, and a view that
+    /// branched on which one it was would be asking a question the shell has already answered.
+    /// </remarks>
+    internal string SessionCrossSurfaceLabel => IsTerminalSurface ? "Open SFTP" : "Open terminal";
+
+    /// <summary>Goes to the other half of the session the sidebar is about.</summary>
+    /// <remarks>
+    /// The two directions were two commands bound from two usages of the header control, and they still are
+    /// two methods — <see cref="SelectFilesHostAsync"/> takes a tab and opens an SFTP connection to its host;
+    /// <see cref="OpenTerminalForFilesHostAsync"/> dials a fresh terminal at whatever SFTP has open, because
+    /// there is no terminal session to reuse. What is new is only that one control now asks for both, so the
+    /// branch lives here beside <see cref="SessionCrossSurfaceLabel"/>, which has to agree with it.
+    /// </remarks>
+    [RelayCommand]
+    private async Task OpenOtherSurfaceAsync()
+    {
+        if (IsTerminalSurface)
+        {
+            if (SelectedTab is { } tab)
+            {
+                await SelectFilesHostAsync(tab).ConfigureAwait(true);
+            }
+
+            return;
+        }
+
+        await OpenTerminalForFilesHostAsync().ConfigureAwait(true);
+    }
+
     /// <summary>
     /// Opens the files screen on the active tab's host and navigates its remote pane to one of its pins.
     /// </summary>
@@ -3896,6 +3990,12 @@ internal sealed partial class MainWindowViewModel : ObservableObject, IAsyncDisp
         if (screen.CanInsert)
         {
             await screen.InsertCommand.ExecuteAsync(null).ConfigureAwait(true);
+
+            // The click that got here took the keyboard off the terminal and gave it to the sidebar row, so
+            // the command lands at a prompt that cannot be typed at until somebody clicks the pane. Asked
+            // for after the insert rather than before it, so the caret arrives to find the text already
+            // there. See TerminalFocusRequested.
+            TerminalFocusRequested?.Invoke(this, EventArgs.Empty);
             return;
         }
 
@@ -3989,14 +4089,15 @@ internal sealed partial class MainWindowViewModel : ObservableObject, IAsyncDisp
     }
 
     /// <summary>
-    /// The account and endpoint the session shell's header and status bar are about right now, or null when
+    /// The account and endpoint the session shell's sidebar and status bar are about right now, or null when
     /// neither surface has one.
     /// </summary>
     /// <remarks>
     /// One property reading whichever surface is showing, rather than one binding per surface reading its own
-    /// source directly — <c>SessionHeader.axaml</c> and <c>SessionStatusBar.axaml</c> are the same markup on
+    /// source directly — <c>SessionSidebar.axaml</c> and <c>SessionStatusBar.axaml</c> are the same markup on
     /// both surfaces precisely because the shell resolves "which fact source" here instead of asking the view
-    /// to. The terminal's is <see cref="SelectedTab"/>'s own address; SFTP's is <see cref="TransfersViewModel.ConnectedTo"/>,
+    /// to. It was the retired header row that printed this first; v5c-4 moved the line into the sidebar's own
+    /// session block and left this property exactly as it was. The terminal's is <see cref="SelectedTab"/>'s own address; SFTP's is <see cref="TransfersViewModel.ConnectedTo"/>,
     /// which is already the account and endpoint actually dialled — nothing here re-derives it.
     /// </remarks>
     internal string? SessionAddress => Surface switch
@@ -4141,6 +4242,10 @@ internal sealed partial class MainWindowViewModel : ObservableObject, IAsyncDisp
         OnPropertyChanged(nameof(SessionIdentityLabel));
         OnPropertyChanged(nameof(SessionIdentityText));
         OnPropertyChanged(nameof(ShowsQuickAccessSidebar));
+
+        // v5c-4: the sidebar's cross-surface row says where the other half of this session is, so it turns
+        // over with the surface exactly as the facts above do.
+        OnPropertyChanged(nameof(SessionCrossSurfaceLabel));
     }
 
     /// <remarks>

src/DodoSSH.Client.Shell/ViewModels/UpdateViewModel.cs

@@ -74,16 +74,6 @@ internal sealed partial class UpdateViewModel : ObservableObject, IAsyncDisposab
     /// </remarks>
     private static readonly TimeSpan CheckInterval = TimeSpan.FromHours(6);
 
-    /// <summary>How long to wait before the first pass.</summary>
-    /// <remarks>
-    /// A delay, where <c>VaultViewModel</c>'s sync loop runs a pass immediately. The difference is what the
-    /// user is waiting for: a vault edited on another machine should be current by the time they have
-    /// finished reading the list, whereas nothing anybody does in their first two minutes depends on an
-    /// update. Launch is already contending for the network and the CPU with a schema migration, a resumed
-    /// sign-in and a first sync, at the one moment somebody is watching the window.
-    /// </remarks>
-    private static readonly TimeSpan FirstCheckDelay = TimeSpan.FromMinutes(2);
-
     private readonly IUpdateChannel updates;
     private readonly ClientSettingsStore settings;
     private readonly TimeProvider clock;
@@ -242,16 +232,40 @@ internal sealed partial class UpdateViewModel : ObservableObject, IAsyncDisposab
         loop = RunCheckLoopAsync(lifetime.Token);
     }
 
+    /// <remarks>
+    /// <para>
+    /// <b>The first pass runs at launch, with no delay in front of it.</b> It used to wait two minutes, on
+    /// the argument that nothing anybody does in their first two minutes depends on an update and launch is
+    /// already contending for the network with a schema migration, a resumed sign-in and a first sync. What
+    /// that argument leaves out is the run that is over before the two minutes are: a client opened to reach
+    /// one host and closed again never checks at all, and a machine used that way is exactly the one ADR
+    /// 0011 warns about — quietly a year behind, with the mechanism to fix it switched on and never reached.
+    /// Every start now asks.
+    /// </para>
+    /// <para>
+    /// <b>The yield is what keeps that off the launch path.</b> <see cref="Start"/> is called from
+    /// <c>MainWindowViewModel.StartAsync</c> before the migration, so running the pass inline would put
+    /// whatever the channel does before its own first await — Velopack reads the install layout from disk —
+    /// between the user and their window. Yielding hands the rest of the launch back and lets the check run
+    /// in a later turn, which is the same moment in every sense that matters and none of the cost.
+    /// </para>
+    /// </remarks>
     private async Task RunCheckLoopAsync(CancellationToken cancellationToken)
     {
         try
         {
-            await Task.Delay(FirstCheckDelay, clock, cancellationToken).ConfigureAwait(true);
+            await Task.Yield();
 
             using var timer = new PeriodicTimer(CheckInterval, clock);
 
             do
             {
+                // Task.Yield takes no token, unlike the delay it replaced, so a shutdown that lands while
+                // the loop is waiting to be handed back the thread has to be observed here rather than
+                // only at the next tick. Otherwise an application closed during launch spends its last
+                // moment asking a release channel about a build it is not going to run.
+                cancellationToken.ThrowIfCancellationRequested();
+
                 await CheckOnceAsync(cancellationToken).ConfigureAwait(true);
             }
             while (await timer.WaitForNextTickAsync(cancellationToken).ConfigureAwait(true));

src/DodoSSH.Client.Shell/ViewModels/VaultViewModel.cs

@@ -11247,10 +11247,7 @@ internal sealed partial class VaultViewModel(
         }
         catch (TimeoutException)
         {
-            Abandon(
+            Abandon(attempt, RendererNeverStarted);
-                attempt,
-                "The terminal did not start, so nothing was connected. The Microsoft Edge WebView2 "
-                + "runtime is probably missing or blocked; install it and try again.");
         }
         catch (SshHostKeyUnknownException exception)
         {
@@ -11275,6 +11272,29 @@ internal sealed partial class VaultViewModel(
         }
     }
 
+    /// <summary>What a renderer that never attached is reported as.</summary>
+    /// <remarks>
+    /// <para>
+    /// The wait is translated rather than reported for the reason <see cref="OpenSessionAsync"/> gives —
+    /// <see cref="TimeoutException"/> says only "The operation has timed out" — and the whole value of the
+    /// translation is naming where to look. Which is why it cannot be one sentence: the desktop's answer is
+    /// a runtime this application does not install, and the phone has no such runtime and no such answer.
+    /// Telling somebody on a handset to install Microsoft Edge WebView2 is worse than saying nothing, at the
+    /// one moment they are trying to work out what went wrong.
+    /// </para>
+    /// <para>
+    /// A runtime check rather than a constructor parameter, for the reason
+    /// <c>MainWindowViewModel.GestureWait</c> records at length: which renderer is behind the terminal is a
+    /// fact about the platform this assembly is running on, not about one installation of it.
+    /// </para>
+    /// </remarks>
+    private static string RendererNeverStarted =>
+        OperatingSystem.IsAndroid()
+            ? "The terminal did not start, so nothing was connected. Android's WebView is probably "
+                + "disabled or updating; check it in Settings and try again."
+            : "The terminal did not start, so nothing was connected. The Microsoft Edge WebView2 "
+                + "runtime is probably missing or blocked; install it and try again.";
+
     /// <summary>Says, in one place, that an attempt ended without a session and why.</summary>
     /// <remarks>
     /// The reason goes to two places on purpose. The status line is where somebody watching this screen is

src/DodoSSH.Client.Shell/WebAssets/terminal.css

@@ -78,6 +78,50 @@ body {
   height: 100%;
 }
 
+/*
+  ── THE BLACK STRIP UNDER THE TERMINAL ───────────────────────────────────────────────────────────────
+  xterm.css paints its scrolling viewport #000 — literally black, and its own comment says why: on macOS
+  the overlay scrollbar is only fully opaque over an opaque backdrop. Everywhere else that black is a
+  surface nobody sees, because the rows cover it — except along the bottom, where they do not. The fit
+  addon floors the row count, so whatever is left of the pane below the last whole row is viewport with
+  nothing drawn on it: a full-width black bar under the terminal, up to one line tall, against this
+  page's own #171a26. On Windows it is also where the classic scrollbar's bottom corner lands, which is
+  the light square at its right-hand end.
+
+  Repainting it in the page's own background is the whole fix. The remainder is still there — it is the
+  cost of a grid that has to divide evenly — but it now reads as the terminal's own margin rather than
+  as a strip of chrome that belongs to something else.
+*/
+.xterm .xterm-viewport {
+  background-color: var(--dodo-background);
+
+  /*
+    And the scrollbar itself, which WebView2 draws in the classic Windows style: a 15-pixel light-grey
+    channel with arrow buttons, down the right of a near-black terminal. Thin and in this page's own
+    colours instead — kept rather than hidden, because the scrollback is real and a surface that scrolls
+    with no sign that it does is worse than a quiet bar saying where you are.
+
+    Both spellings. scrollbar-width/-color is the standard one and is what current WebView2 and WebKitGTK
+    honour; ::-webkit-scrollbar is what older Chromium builds and WKWebView answer to. Neither is
+    load-bearing on its own and the two do not conflict — whichever the host understands wins.
+  */
+  scrollbar-width: thin;
+  scrollbar-color: color-mix(in srgb, var(--dodo-muted) 45%, transparent) transparent;
+}
+
+.xterm .xterm-viewport::-webkit-scrollbar {
+  width: 9px;
+}
+
+.xterm .xterm-viewport::-webkit-scrollbar-track {
+  background: transparent;
+}
+
+.xterm .xterm-viewport::-webkit-scrollbar-thumb {
+  background: color-mix(in srgb, var(--dodo-muted) 45%, transparent);
+  border-radius: 5px;
+}
+
 #status {
   position: absolute;
   left: 0;

src/DodoSSH.Client.Shell/WebAssets/terminal.js

@@ -84,14 +84,57 @@ const RELEASE_FOCUS_MESSAGE = 'dodossh.release-focus';
 const root = document.getElementById('root');
 const statusBanner = document.getElementById('status');
 
-/** @type {Map<number, {term: object, fit: object, pane: HTMLElement}>} */
+/** @type {Map<number, {term: object, fit: object, pane: HTMLElement, notice: string}>} */
 const sessions = new Map();
 
 /** @type {WebSocket | null} */
 let socket = null;
 
-function setStatus(text) {
+/** Whose pane is showing, or null before there is one — see activate(). */
-  statusBanner.textContent = text ?? '';
+let activeSessionId = null;
+
+/*
+  ── THE BANNER BELONGS TO ONE PANE AT A TIME ─────────────────────────────────────────────────────────
+  There is one #status element for the whole page, because there is one page for every terminal: the
+  panes are stacked in the same box and all but the active one are hidden. What goes in it comes from
+  two sources that are not the same size, and the difference is the whole of this.
+
+  The socket's troubles are the page's. There is a single socket behind every pane, so "the view is
+  reconnecting" is true of whatever is on screen and true of the panes behind it.
+
+  A session's last words are not. "The remote closed the session." is a fact about one terminal and says
+  nothing whatever about the others — so it is held on the session and drawn only while that session's
+  pane is the one showing. Written straight into the shared element, which is what this used to do, it
+  outlived the tab it described: switching to a live terminal left the dead one's epitaph sitting under
+  it, and opening or closing any other tab wiped the message whether or not it belonged to that tab.
+
+  The socket's half wins when both have something to say: a page whose socket is down is not showing
+  live output on any pane, which makes what became of one session the less urgent of the two.
+*/
+let transportStatus = statusBanner.textContent ?? '';
+
+function renderStatus() {
+  const notice = activeSessionId === null ? '' : sessions.get(activeSessionId)?.notice ?? '';
+
+  statusBanner.textContent = transportStatus || notice;
+}
+
+/** Says something about the socket, which every pane shares. */
+function setTransportStatus(text) {
+  transportStatus = text ?? '';
+  renderStatus();
+}
+
+/** Records what became of one session, to be drawn only while that session's pane is showing. */
+function setSessionNotice(sessionId, text) {
+  const session = sessions.get(sessionId);
+
+  if (!session) {
+    return;
+  }
+
+  session.notice = text ?? '';
+  renderStatus();
 }
 
 /** Builds a frame: opcode, big-endian session id, then payload. */
@@ -255,8 +298,31 @@ function createSession(sessionId) {
   // WebGL where it is available. Falling back rather than failing matters because a software
   // renderer is slow but usable, whereas a blank pane is not — and remote desktops and VMs
   // routinely have no usable GPU context.
+  //
+  // ◆ THE CONTEXT-LOSS HANDLER IS THE HALF THAT WAS MISSING, AND ON A PHONE IT IS THE WHOLE THING.
+  //
+  // The addon does not recover from a lost GPU context by itself, and it does not fail loudly either:
+  // it stays loaded over a dead context and draws nothing at all. What that looks like from outside is
+  // a terminal that is connected, still accepting keystrokes, still acknowledging output — and blank.
+  // xterm's own guidance is to dispose the addon and let the DOM renderer take over, which is what this
+  // does; the addon is not reloaded afterwards, because a pane that lost the context once is on a
+  // surface that will do it again and thrashing between renderers is worse than being slow.
+  //
+  // Losing it is ordinary on Android and nearly unheard of on Windows, which is why this went unnoticed
+  // for so long. Collapsing the renderer sets the native view to GONE — see
+  // AndroidNativeControlHostImpl.HideWithSize — and a WebView with no surface has no GL context. The
+  // shell collapses it every time a tab starts connecting, every time the connect sheet opens and every
+  // time the app is backgrounded, so on a phone the first loss arrives within seconds of the first
+  // session. WebView2 hides a child HWND instead and keeps rendering throughout; see
+  // docs/platform-flags.md.
   try {
-    term.loadAddon(new WebglAddon.WebglAddon());
+    const webgl = new WebglAddon.WebglAddon();
+
+    // Subscribed before loadAddon, because loadAddon is what activates the addon and a context that is
+    // already gone can be reported from inside that call.
+    webgl.onContextLoss(() => webgl.dispose());
+
+    term.loadAddon(webgl);
   } catch (error) {
     console.warn('WebGL renderer unavailable; falling back to canvas.', error);
   }
@@ -269,7 +335,7 @@ function createSession(sessionId) {
 
   term.onResize(() => sendResize(sessionId, term, pane));
 
-  const session = { term, fit, pane };
+  const session = { term, fit, pane, notice: '' };
   sessions.set(sessionId, session);
 
   activate(sessionId);
@@ -283,6 +349,11 @@ function activate(sessionId) {
     session.pane.dataset.active = String(id === sessionId);
   }
 
+  // The banner follows the pane. Whatever this session has to say for itself replaces whatever the
+  // session that was showing had to say for its own, which is the point of holding it per session.
+  activeSessionId = sessionId;
+  renderStatus();
+
   const active = sessions.get(sessionId);
   if (active) {
     active.term.focus();
@@ -296,10 +367,17 @@ function activate(sessionId) {
 // caller, because more than one path reaches here: a minimised window, and a splitter dragged to the edge
 // once splits land.
 //
-// It is *not* what protects the vault's lock screen, which an earlier version of this comment claimed.
+// It is *not* what protects the vault's lock screen on the desktop, which an earlier version of this
-// Collapsing the host's WebView hides a native child window without resizing it, so this page's viewport
+// comment claimed. Collapsing WebView2 hides a native child window without resizing it, so this page's
-// does not change, no observer fires and this function is never called — measured with a live shell, and
+// viewport does not change, no observer fires and this function is never called — measured with a live
-// confirmed by removing the guard and finding the lock cycle equally clean. See docs/platform-flags.md.
+// shell, and confirmed by removing the guard and finding the lock cycle equally clean. See
+// docs/platform-flags.md.
+//
+// On the phone it *is* load-bearing, and that is the one place the two heads differ here. Android hides a
+// native child by setting it GONE, and a GONE view is skipped by its parent's layout — so collapsing the
+// renderer really does take this page's viewport to nothing, the observer really does fire, and without
+// the guard every lock, every connect sheet and every trip to the background would reflow the remote pty
+// to 2x1 and mangle the scrollback it wrapped.
 const MINIMUM_FITTABLE_PIXELS = 40;
 
 function resize(session, sessionId) {
@@ -343,7 +421,10 @@ function handleFrame(buffer) {
         session.term.write(REPLAY_BANNER);
       }
 
-      setStatus('');
+      // This session's own line, and only this one's: a session that is open has nothing to say about
+      // how it ended. The page's own "Connecting…" is cleared by the socket opening, which happens
+      // before any frame can arrive.
+      setSessionNotice(sessionId, '');
       break;
     }
 
@@ -396,7 +477,14 @@ function handleFrame(buffer) {
       session.pane.remove();
       sessions.delete(sessionId);
 
-      setStatus('');
+      // The notice went with the session record it was held on, but the page can still be pointing at
+      // the pane that is now gone. Cleared rather than left dangling, so the banner stops describing a
+      // closed tab while the host decides which pane to show next.
+      if (activeSessionId === sessionId) {
+        activeSessionId = null;
+      }
+
+      renderStatus();
       break;
     }
 
@@ -417,8 +505,23 @@ function handleFrame(buffer) {
         is something only this page sees — and a shell that receives a multi-line command inside those
         markers treats every newline as text. Without them it treats each one as "run this", so a
         three-line snippet runs three commands the moment it is inserted.
+
+        ◆ ONE LINE IS TYPED INSTEAD, and this is not an optimisation. Bracketed paste is what readline
+        uses to decide it has been pasted into, and bash marks the result as an active region: the
+        inserted command sits at the prompt in reverse video, looking selected, until the next
+        keystroke clears it. That is right for a paste somebody made with the clipboard and wrong for a
+        snippet they picked off the sidebar, which should read as though they had typed it.
+
+        The markers are only load-bearing for text carrying a newline — that is the whole of what the
+        paragraph above protects against — so a single-line snippet does not need them and is written
+        as keystrokes. Multi-line still pastes, highlight and all, because "runs three commands
+        unasked" is the worse of the two.
       */
-      session.term.paste(text);
+      if (text.includes('\n') || text.includes('\r')) {
+        session.term.paste(text);
+      } else {
+        session.term.input(text);
+      }
 
       /*
         And the Enter goes through input(), deliberately outside that wrapper. A '\r' appended to the
@@ -430,6 +533,15 @@ function handleFrame(buffer) {
         session.term.input('\r');
       }
 
+      /*
+        The caret goes back where the text landed. Half of it, anyway: this reaches
+        document.activeElement and nothing further, so it is what makes the pane the page's own focused
+        element and what stops a hidden textarea from keeping the caret. The other half is Win32
+        focus — the sidebar row that sent this frame took it — and only the host can give that back;
+        see MainWindowViewModel.TerminalFocusRequested and MainWindow's own FocusTerminalWhenLaidOut.
+      */
+      session.term.focus();
+
       break;
     }
 
@@ -449,14 +561,19 @@ function handleFrame(buffer) {
       const session = sessions.get(sessionId);
       const reason = new TextDecoder().decode(payload);
 
-      if (session) {
+      if (!session) {
-        // The pane and its scrollback stay. The user was probably reading the last thing the
+        // No pane, so there is nothing this page can honestly hang the reason on. It used to go into
-        // remote said, and that is usually why the session ended.
+        // the banner anyway, which printed one session's ending underneath whichever pane happened to
-        session.term.write(`\r\n\x1b[38;5;244m── ${reason} ──\x1b[0m\r\n`);
+        // be showing at the time.
-        session.term.options.cursorBlink = false;
+        break;
       }
 
-      setStatus(reason);
+      // The pane and its scrollback stay. The user was probably reading the last thing the
+      // remote said, and that is usually why the session ended.
+      session.term.write(`\r\n\x1b[38;5;244m── ${reason} ──\x1b[0m\r\n`);
+      session.term.options.cursorBlink = false;
+
+      setSessionNotice(sessionId, reason);
       break;
     }
 
@@ -481,7 +598,7 @@ function scheduleReconnect() {
     return;
   }
 
-  setStatus('Reconnecting the terminal view…');
+  setTransportStatus('Reconnecting the terminal view…');
 
   reconnectTimer = setTimeout(() => {
     reconnectTimer = null;
@@ -501,7 +618,7 @@ function connect() {
   socket.binaryType = 'arraybuffer';
 
   socket.addEventListener('open', () => {
-    setStatus('');
+    setTransportStatus('');
 
     // Back to the quick attempt for whatever the next failure turns out to be. Kept slow between
     // attempts within one outage, reset once the outage is actually over.

src/DodoSSH.Contracts/packages.lock.json

@@ -22,9 +22,9 @@
       },
       "Microsoft.NET.ILLink.Tasks": {
         "type": "Direct",
-        "requested": "[10.0.10, )",
+        "requested": "[10.0.11, )",
-        "resolved": "10.0.10",
+        "resolved": "10.0.11",
-        "contentHash": "f5VCIE7AJpd5YvzNTeMGVzQIgyE9tX+AreTYwQF+REbu+DZo/2Ae+jNSwhPEYrVz6RRkd7y8ubXjk6Nn6Ka+Cg=="
+        "contentHash": "IBf7lbovvjGWVWXZX5cJ/cO0WXbId0Zq4BuSeT94mGZuOAP66oMeH9PTBZ9Jpp3Jb6jtK0qm/NyUbPRo1gC/wQ=="
       },
       "MinVer": {
         "type": "Direct",

src/DodoSSH.Crypto/packages.lock.json

@@ -16,9 +16,9 @@
       },
       "Microsoft.NET.ILLink.Tasks": {
         "type": "Direct",
-        "requested": "[10.0.10, )",
+        "requested": "[10.0.11, )",
-        "resolved": "10.0.10",
+        "resolved": "10.0.11",
-        "contentHash": "f5VCIE7AJpd5YvzNTeMGVzQIgyE9tX+AreTYwQF+REbu+DZo/2Ae+jNSwhPEYrVz6RRkd7y8ubXjk6Nn6Ka+Cg=="
+        "contentHash": "IBf7lbovvjGWVWXZX5cJ/cO0WXbId0Zq4BuSeT94mGZuOAP66oMeH9PTBZ9Jpp3Jb6jtK0qm/NyUbPRo1gC/wQ=="
       },
       "MinVer": {
         "type": "Direct",

tests/DodoSSH.Client.App.Layout.Tests/LayoutHarness.cs

@@ -122,8 +122,14 @@ internal static class LayoutHarness
     /// <summary>The v5b session shell's own right-hand sidebar, from <c>SessionSidebar.axaml</c>.</summary>
     internal const double SessionSidebarWidth = 300;
 
-    /// <summary>The v5b session shell's own host header, from <c>SessionHeader.axaml</c>.</summary>
+    /*
-    internal const double SessionHeaderHeight = 60;
+      A third session-shell constant stood here through wave B and C: SessionHeaderHeight, 60 pixels, for
+      the host header that sat above the pane on both surfaces. v5c-4 retires that row — its address and
+      its cross-surface button both live in the sidebar now; see SessionSidebar.axaml — so the pane between
+      the tab row and the status bar is 60 pixels taller and this budget no longer subtracts anything for
+      it. The same treatment the retired window-wide tab strip got above, and for the same reason: a
+      constant for chrome that is not drawn is a budget that quietly under-measures every screen.
+    */
 
     /// <summary>The v5b session shell's own status bar, from <c>SessionStatusBar.axaml</c>.</summary>
     internal const double SessionStatusBarHeight = 37;
@@ -146,12 +152,12 @@ internal static class LayoutHarness
     /// The arithmetic, top to bottom: <see cref="ScreenHeight"/> less <see cref="SessionShellPadding"/> on
     /// both the top and the bottom of the outer padded column, less <see cref="SessionTabRowHeight"/> for the
     /// tab row that sits above the bordered container, less <see cref="SessionShellBorderThickness"/> on both
-    /// the top and the bottom of that border, less <see cref="SessionHeaderHeight"/> and
+    /// the top and the bottom of that border, less <see cref="SessionStatusBarHeight"/> for the one fixed
-    /// <see cref="SessionStatusBarHeight"/> for the two fixed strips the pane sits between.
+    /// strip left below the pane — v5c-4 retired the header above it; see the note where its constant was.
     /// </remarks>
     internal static double SessionScreenHeight =>
         ScreenHeight - (2 * SessionShellPadding) - SessionTabRowHeight - (2 * SessionShellBorderThickness)
-        - SessionHeaderHeight - SessionStatusBarHeight;
+        - SessionStatusBarHeight;
 
     /// <summary>
     /// The width a session-shell screen gets, with or without <c>SessionSidebar</c>'s own QUICK ACCESS

tests/DodoSSH.Client.App.Layout.Tests/NavRailTests.cs

@@ -1,8 +1,10 @@
 using Avalonia;
 using Avalonia.Controls;
+using Avalonia.Controls.Presenters;
 using Avalonia.Controls.Primitives;
 using Avalonia.Headless;
 using Avalonia.Input;
+using Avalonia.Media;
 using Avalonia.VisualTree;
 using DodoSSH.Client.App.Views;
 using DodoSSH.Client.Session;
@@ -272,6 +274,49 @@ public sealed class NavRailTests : IAsyncLifetime
         });
     }
 
+    /// <summary>
+    /// Every row in the popover rests flat, and the pointer is what fills one.
+    /// </summary>
+    /// <remarks>
+    /// <c>Button.poprow</c> set a radius and a padding and left the Background alone, so each row wore the
+    /// Fluent theme's own button fill: the account menu drew as six raised pills where the design draws six
+    /// lines of text. Read as a colour off the templated presenter rather than off the Button, because that
+    /// is where the theme puts its brush and therefore the only place the absence of one can be proven.
+    ///
+    /// The hover half is asserted too, and it is what stops "flat" being fixed by making the rows
+    /// permanently invisible to the pointer: a menu row that does not answer a pointer at all is a worse
+    /// answer than one that answers wrongly.
+    /// </remarks>
+    [Fact]
+    public async Task PopoverRowsAreFlatUntilThePointerFindsThem()
+    {
+        await OnTheRailAsync((rail, window) =>
+        {
+            Click(UserChip(rail), window);
+
+            var row = PopoverRow(window, "Settings");
+            var presenter = row.GetVisualDescendants()
+                .OfType<ContentPresenter>()
+                .First(candidate => candidate.Name is "PART_ContentPresenter");
+
+            var resting = presenter.Background as ISolidColorBrush;
+
+            (resting is null || resting.Color.A == 0).ShouldBeTrue(
+                $"a popover row rests flat, and this one is filled with {resting?.Color}");
+
+            var centre = row.TranslatePoint(new Point(row.Bounds.Width / 2, row.Bounds.Height / 2), window)
+                ?? throw new InvalidOperationException("the row is not in this window's tree");
+
+            window.MouseMove(centre);
+            LayoutHarness.Settle(window, LayoutHarness.NavRailWidth, LayoutHarness.ScreenHeight);
+
+            row.IsPointerOver.ShouldBeTrue("the pointer was moved onto it");
+            (presenter.Background as ISolidColorBrush).ShouldNotBeNull().Color.A.ShouldNotBe(
+                (byte)0,
+                "a row that does not change under the pointer is one nobody can tell is clickable");
+        });
+    }
+
     // ---- Helpers ----
 
     private Task OnTheRailAsync(Action<NavRail, Window> body) =>

tests/DodoSSH.Client.App.Layout.Tests/ScreenLayoutTests.cs

@@ -1274,7 +1274,7 @@ public sealed class ScreenLayoutTests : IAsyncLifetime
     /// this screen — see <c>ShowsQuickAccessSidebar</c> — so this is the test that actually reaches the
     /// 472-pixel budget <see cref="LayoutHarness.SessionScreenWidth"/> computes, 204 pixels a side. DISCONNECT
     /// is what is left in the remote pane's own connected strip now; the account-at-host chip that used to
-    /// share the row with it moved out, because <c>SessionHeader</c> already prints the same address above
+    /// share the row with it moved out, because the session shell already prints the same address beside
     /// this screen — see <c>TransfersScreen.axaml</c>'s own remark on the strip for why keeping both was the
     /// thing squeezing DISCONNECT off the edge at this width.
     /// </para>
@@ -1596,7 +1596,7 @@ public sealed class ScreenLayoutTests : IAsyncLifetime
     /// <remarks>
     /// <para>
     /// v5b's redraw changes what this test has to hold. Three button shapes live in the rail now rather
-    /// than one: the switcher's three segments, each a third of the rail's own content width; the six item
+    /// than one: the switcher's three segments, each a third of the rail's own content width; the five item
     /// rows below it and the user chip at the foot, both the rail's full content width. A single
     /// across-the-board width assertion the way the v3 version of this test made one would either be wrong
     /// for the segments or have to loosen until it caught nothing, so each shape gets its own count and its
@@ -1604,13 +1604,18 @@ public sealed class ScreenLayoutTests : IAsyncLifetime
     /// </para>
     /// <para>
     /// The rail runs vertically, so what runs out at the window's minimum is still height — a switcher plus
-    /// six rows plus a user chip have to leave room for each other in the same space the v3 rail's seven
+    /// five rows plus a user chip have to leave room for each other in the same space the v3 rail's seven
     /// plain rows did. Both counts are asserted in both directions for the reason the old test's was: an
     /// entry silently dropping off the bottom would still pass every other assertion here.
     /// </para>
+    /// <para>
+    /// Five and not six since Pins left the rail: the pins screen is reached from "Host keys" on the Keys
+    /// screen, which was always the other way in. Exact rather than a bound, so putting a row back is a
+    /// decision somebody makes here rather than something that slips in.
+    /// </para>
     /// </remarks>
     [Fact]
-    public async Task TheNavRailHoldsItsSwitcherSixDestinationsAndTheUserChipAtTheWindowsMinimum()
+    public async Task TheNavRailHoldsItsSwitcherFiveDestinationsAndTheUserChipAtTheWindowsMinimum()
     {
         await LayoutHarness.OnTheUiThreadAsync(
             () =>
@@ -1630,7 +1635,7 @@ public sealed class ScreenLayoutTests : IAsyncLifetime
 
                     segments.Count.ShouldBe(3, "SSH, SFTP and S3");
                     rows.Count.ShouldBe(
-                        6, "the mode-dependent first row, then Hosts, Keys, Pins, Snips and Logs");
+                        5, "the mode-dependent first row, then Hosts, Keys, Snips and Logs");
 
                     foreach (var segment in segments)
                     {

tests/DodoSSH.Client.App.Layout.Tests/SessionSidebarTests.cs

@@ -0,0 +1,184 @@
+using Avalonia;
+using Avalonia.Controls;
+using Avalonia.Headless;
+using Avalonia.Input;
+using Avalonia.VisualTree;
+using DodoSSH.Client.App.Views;
+using DodoSSH.Client.Session;
+using DodoSSH.Client.Shell.ViewModels;
+using DodoSSH.Client.Ssh;
+using DodoSSH.Client.Storage;
+using DodoSSH.Client.Terminal;
+using NSubstitute;
+
+namespace DodoSSH.Client.App.Layout.Tests;
+
+/// <summary>
+/// The session shell's right-hand column: its two widths, and what a long address does to the row it shares.
+/// </summary>
+/// <remarks>
+/// Worth a suite of its own since v5c-4, which gave this control two things it did not have: a session block
+/// at its head — the address, and the cross-surface button, both inherited from the 60-pixel header row that
+/// pass retired — and a closed state. The first is exactly the shape this harness exists for, a fixed-width
+/// column holding a string of unbounded length beside a button that must stay clickable; the second is a
+/// width the rest of the window has to cope with, and <c>MainWindow.axaml</c> copes with it by asking this
+/// control how wide it is rather than by knowing.
+/// </remarks>
+public sealed class SessionSidebarTests : IAsyncLifetime
+{
+    /// <summary>The widths <c>SessionSidebar.axaml</c> declares for its two states.</summary>
+    private const double OpenWidth = 300;
+
+    /// <inheritdoc cref="OpenWidth" />
+    private const double RailWidth = 34;
+
+    /// <remarks>
+    /// Long on purpose, and longer than the column is wide at this font: the address is the one string here
+    /// whose length nobody controls, and it shares its row with the button that closes the column.
+    /// </remarks>
+    private const string LongAddress = "a-very-long-deploy-account@db-primary.eu-west-1.internal.example:22022";
+
+    private string directory = null!;
+    private ClientCacheFactory caches = null!;
+    private TerminalWorkspace workspace = null!;
+    private MainWindowViewModel shell = null!;
+
+    private static CancellationToken Token => TestContext.Current.CancellationToken;
+
+    /// <inheritdoc />
+    public ValueTask InitializeAsync()
+    {
+        // A profile of this test's own rather than ClientPaths.Default: closing the sidebar is written
+        // through to disk — see ClientSettings.SessionSidebarOpen — and a suite that used the default paths
+        // would be editing the preferences of whoever ran it.
+        directory = Path.Combine(Path.GetTempPath(), $"dodossh-sidebar-{Guid.CreateVersion7():N}");
+        caches = ClientCacheFactory.ForMemory($"session-sidebar-{Guid.CreateVersion7():N}");
+
+        workspace = new TerminalWorkspace(
+            new InMemoryTerminalAssetProvider(new Dictionary<string, TerminalAsset>(StringComparer.Ordinal)),
+            Substitute.For<ISshConnectionFactory>(),
+            TimeProvider.System);
+
+        shell = new MainWindowViewModel(
+            new ClientPaths(directory),
+            caches,
+            workspace,
+            new VaultKnownHostStore(),
+            Substitute.For<IDeviceKeyStore>(),
+            (_, _) => throw new NotSupportedException("nothing here signs in"),
+            TimeProvider.System,
+            Substitute.For<ISftpSessionFactory>())
+        {
+            State = ShellState.Unlocked,
+        };
+
+        return ValueTask.CompletedTask;
+    }
+
+    /// <inheritdoc />
+    public async ValueTask DisposeAsync()
+    {
+        await shell.DisposeAsync();
+        await workspace.DisposeAsync();
+        caches.Dispose();
+
+        if (Directory.Exists(directory))
+        {
+            Directory.Delete(directory, recursive: true);
+        }
+    }
+
+    /// <remarks>
+    /// The address trims and the close button stays where it is; that is the whole claim. Asserted through
+    /// <see cref="LayoutHarness.Unreachable"/> rather than by reading the address's own width, because what
+    /// matters is not how much of the string is shown — an ellipsis is an honest answer — but that nothing
+    /// beside it was pushed out of the column to make room.
+    /// </remarks>
+    [Fact]
+    public async Task TheColumnIsThreeHundredWide_AndALongAddressPushesNothingOutOfIt()
+    {
+        await OnTheSidebarAsync((sidebar, window) =>
+        {
+            // DesiredSize rather than Bounds, and that distinction is the control's own: the width lives on
+            // the Border inside it, so what the surrounding "Auto" column is given — and what this asks for
+            // — is what the control asks for, not how wide a host window happened to stretch it.
+            sidebar.DesiredSize.Width.ShouldBe(OpenWidth);
+
+            shell.SessionAddress.ShouldBe(LongAddress, "the fixture selected a tab with one");
+
+            LayoutHarness.Unreachable(window).ShouldBeEmpty();
+        });
+    }
+
+    /// <remarks>
+    /// The cross-surface button that used to live in the header row. Read off the control rather than off the
+    /// view model, so a row bound to the wrong property — or to nothing, which a compiled binding would still
+    /// draw as an empty button — fails this.
+    /// </remarks>
+    [Fact]
+    public async Task TheCrossSurfaceButtonNamesTheOtherSurface()
+    {
+        await OnTheSidebarAsync((sidebar, _) =>
+        {
+            var button = sidebar.GetVisualDescendants()
+                .OfType<Button>()
+                .First(candidate => candidate.Classes.Contains("headerghost"));
+
+            button.Content.ShouldBe("Open SFTP");
+        });
+    }
+
+    /// <remarks>
+    /// Closed, the control is still drawn and is still the thing the window asks for a width — see
+    /// <c>MainWindow.axaml</c>'s own "Auto" column. What it must not be is nothing: a rail with the way back
+    /// on it is the difference between a panel somebody closed and a panel somebody lost.
+    /// </remarks>
+    [Fact]
+    public async Task ClosingTheColumnLeavesTheRailThatBringsItBack()
+    {
+        await OnTheSidebarAsync((sidebar, window) =>
+        {
+            shell.IsSessionSidebarOpen = false;
+            LayoutHarness.Settle(window, LayoutHarness.MinimumWidth, LayoutHarness.MinimumHeight);
+
+            sidebar.DesiredSize.Width.ShouldBe(RailWidth);
+
+            var grip = sidebar.GetVisualDescendants()
+                .OfType<Button>()
+                .Single(candidate => candidate.Classes.Contains("sidebargrip") && candidate.IsEffectivelyVisible);
+
+            var centre = grip.TranslatePoint(new Point(grip.Bounds.Width / 2, grip.Bounds.Height / 2), window)
+                ?? throw new InvalidOperationException("the grip is not in this window's tree");
+
+            window.MouseDown(centre, MouseButton.Left);
+            window.MouseUp(centre, MouseButton.Left);
+
+            shell.IsSessionSidebarOpen.ShouldBeTrue("the rail's own button is what reopens the column");
+
+            LayoutHarness.Settle(window, LayoutHarness.MinimumWidth, LayoutHarness.MinimumHeight);
+            sidebar.DesiredSize.Width.ShouldBe(OpenWidth);
+        });
+    }
+
+    private Task OnTheSidebarAsync(Action<SessionSidebar, Window> body) =>
+        LayoutHarness.OnTheUiThreadAsync(
+            () =>
+            {
+                shell.Tabs.Add(new TerminalTabViewModel(1, "db-primary", LongAddress));
+                shell.SelectTabCommand.Execute(shell.Tabs[0]);
+
+                var sidebar = new SessionSidebar { DataContext = shell, ShowsSnips = true };
+                var window = LayoutHarness.HostAtMinimumSize(
+                    sidebar, LayoutHarness.MinimumWidth, LayoutHarness.MinimumHeight);
+
+                try
+                {
+                    body(sidebar, window);
+                }
+                finally
+                {
+                    window.Close();
+                }
+            },
+            Token);
+}

tests/DodoSSH.Client.App.Layout.Tests/TitleBarTests.cs

@@ -101,4 +101,59 @@ public sealed class TitleBarTests : IAsyncLifetime
             },
             Token);
     }
+
+    /// <remarks>
+    /// The chip that says which chord opens the pill beside it. The design's own is 34 pixels wide because
+    /// the design's own label is ⌘K — two glyphs — and this build substitutes "CTRL K", which at 10.5 mono is
+    /// wider than that. It shipped clipped: the chip drew "CTRL" and half of the K, which reads as a rendering
+    /// glitch rather than as a keyboard shortcut.
+    ///
+    /// Asserted as "the chip is at least as wide as its own text", not against a number. A pixel count would
+    /// have to be re-derived by hand every time the font, the size or the wording moved, and the thing that
+    /// actually matters is the relationship between the two.
+    /// </remarks>
+    [Fact]
+    public async Task TheKeyboardChipIsWideEnoughForTheChordItNames()
+    {
+        await LayoutHarness.OnTheUiThreadAsync(
+            () =>
+            {
+                var bar = new TitleBar { DataContext = shell };
+                var window = LayoutHarness.HostAtMinimumSize(
+                    bar, LayoutHarness.MinimumWidth, LayoutHarness.TitleBarHeight);
+
+                try
+                {
+                    var label = bar.GetVisualDescendants()
+                        .OfType<TextBlock>()
+                        .Single(text => string.Equals(text.Text, "CTRL K", StringComparison.Ordinal));
+
+                    var chip = label.GetVisualAncestors().OfType<Border>().First();
+
+                    // Measured on a copy under an unbounded constraint, not read off the label in the tree.
+                    // A TextBlock's own DesiredSize is already clipped to what it was given, so the laid-out
+                    // one reports 34 inside a 34-pixel chip whether or not the text fits — which is exactly
+                    // the state this test exists to fail on.
+                    var natural = new TextBlock
+                    {
+                        Text = label.Text,
+                        FontFamily = label.FontFamily,
+                        FontSize = label.FontSize,
+                        FontWeight = label.FontWeight,
+                    };
+
+                    natural.Measure(Size.Infinity);
+
+                    natural.DesiredSize.Width.ShouldBeGreaterThan(0, "the chord is a real run of text");
+                    chip.Bounds.Width.ShouldBeGreaterThanOrEqualTo(
+                        natural.DesiredSize.Width,
+                        "a chip narrower than its own label draws part of the chord and cuts the rest");
+                }
+                finally
+                {
+                    window.Close();
+                }
+            },
+            Token);
+    }
 }

tests/DodoSSH.Client.App.Tests/ShellFlowTests.cs

@@ -6498,12 +6498,68 @@ public sealed class ShellFlowTests : IAsyncLifetime
         shell.IsTerminalShowing.ShouldBeTrue();
     }
 
+    /// <remarks>
+    /// v5c-4 retired the session shell's own header row and moved its cross-surface button into the sidebar,
+    /// where one control is drawn on both surfaces — so the two directions above are reached through one
+    /// command and one label, resolved by the shell. This is that resolution: the same two outcomes the two
+    /// tests above assert, from the row a user actually clicks now.
+    /// </remarks>
+    [Fact]
+    public async Task TheSidebarsCrossSurfaceRow_NamesAndOpensWhicheverSurfaceIsNotShowing()
+    {
+        await ConnectedHostWithAPinAsync();
+
+        shell.IsTerminalSurface.ShouldBeTrue();
+        shell.SessionCrossSurfaceLabel.ShouldBe("Open SFTP");
+
+        await shell.OpenOtherSurfaceCommand.ExecuteAsync(null);
+
+        shell.IsTransfersShowing.ShouldBeTrue();
+        shell.Transfers.SelectedHost.ShouldNotBeNull().Label.ShouldBe("prod-db");
+        shell.SessionCrossSurfaceLabel.ShouldBe("Open terminal", "the row turns over with the surface");
+
+        var tabsBefore = shell.Tabs.Count;
+
+        await shell.OpenOtherSurfaceCommand.ExecuteAsync(null);
+
+        shell.Tabs.Count.ShouldBe(tabsBefore + 1, "the other direction dials a terminal at the browsed host");
+        shell.IsTerminalShowing.ShouldBeTrue();
+    }
+
+    /// <remarks>
+    /// Closing the sidebar is a preference about this machine, so it outlives the window — see
+    /// <c>ClientSettings.SessionSidebarOpen</c>. Asserted against the store rather than against a second
+    /// shell built over the same profile: what a fresh launch reads is exactly what is on disk, and building
+    /// another shell here would prove the constructor twice and the storage once.
+    /// </remarks>
+    [Fact]
+    public async Task ClosingTheSidebar_IsRememberedForTheNextLaunch()
+    {
+        await ConnectedHostWithAPinAsync();
+
+        shell.IsSessionSidebarOpen.ShouldBeTrue("open is the default, and nothing has closed it");
+
+        shell.ToggleSessionSidebarCommand.Execute(null);
+
+        shell.IsSessionSidebarOpen.ShouldBeFalse();
+        new ClientSettingsStore(paths).Read().SessionSidebarOpen.ShouldBeFalse();
+
+        shell.ToggleSessionSidebarCommand.Execute(null);
+
+        shell.IsSessionSidebarOpen.ShouldBeTrue();
+        new ClientSettingsStore(paths).Read().SessionSidebarOpen.ShouldBeTrue("and reopening is remembered too");
+    }
+
     /// <remarks>
     /// The sidebar's SNIPS row, wired through <c>SnippetsViewModel.InsertCommand</c> rather than a second
     /// insert path — see the deviation recorded on <c>MainWindowViewModel.InsertSnippetCommand</c>. Proven
     /// through a real connected tab and a real renderer, the same fixture <c>InsertingASnippet_...</c> above
     /// uses for the standalone screen, because what is worth proving here is that the shell's command reaches
     /// that same mechanism rather than reimplementing it.
+    ///
+    /// The focus request is asserted here rather than in a test of its own because it is part of what this
+    /// click does: the row that typed the command took the keyboard with it, and only the window can give it
+    /// back. See <c>MainWindowViewModel.TerminalFocusRequested</c>.
     /// </remarks>
     [Fact]
     public async Task InsertingASnippetFromTheSidebarTypesItIntoTheSelectedTab()
@@ -6515,9 +6571,38 @@ public sealed class ShellFlowTests : IAsyncLifetime
 
         var row = snippets.Visible.ShouldHaveSingleItem();
 
+        var focusRequests = 0;
+        shell.TerminalFocusRequested += (_, _) => focusRequests++;
+
         await shell.InsertSnippetCommand.ExecuteAsync(row);
 
         snippets.Selected.ShouldBe(row, "the sidebar row picks the same selection INSERT reads");
+        focusRequests.ShouldBe(1, "the keyboard goes back to the terminal the command landed in");
+    }
+
+    /// <remarks>
+    /// The other half of the rule above: nothing was typed, so nothing asks for the keyboard. A snip clicked
+    /// with no terminal to put it in lands on the snippets screen instead — see
+    /// <c>MainWindowViewModel.InsertSnippetCommand</c> — and stealing focus into a collapsed WebView on the
+    /// way would leave that screen unable to be typed on.
+    /// </remarks>
+    [Fact]
+    public async Task InsertingASnippetWithNothingToInsertInto_DoesNotAskForTheTerminal()
+    {
+        await UnlockedAsync();
+
+        var snippets = shell.SnippetsScreen.ShouldNotBeNull();
+        await AddSnippetAsync(snippets, "uptime", "uptime", runs: false);
+
+        var row = snippets.Visible.ShouldHaveSingleItem();
+
+        var focusRequests = 0;
+        shell.TerminalFocusRequested += (_, _) => focusRequests++;
+
+        await shell.InsertSnippetCommand.ExecuteAsync(row);
+
+        shell.Screen.ShouldBe(ShellScreen.Snippets);
+        focusRequests.ShouldBe(0);
     }
 
     [Fact]

tests/DodoSSH.Client.App.Tests/UpdateFlowTests.cs

@@ -403,6 +403,46 @@ public sealed class UpdateFlowTests : IDisposable
         channel.Checks.ShouldBe(1);
     }
 
+    /// <remarks>
+    /// <para>
+    /// The loop rather than <c>CheckOnceAsync</c>, which is the one thing the rest of this file avoids
+    /// driving — and here it is the whole point, because the claim is about when the first pass happens
+    /// rather than about what it does. The first pass used to wait two minutes, which meant a client opened
+    /// to reach one host and closed again never asked at all.
+    /// </para>
+    /// <para>
+    /// It waits on the pass and not on a clock, so there is nothing here to be flaky about: a regression
+    /// that puts a delay back in front of the loop does not fail on a margin, it spins until the suite's own
+    /// cancellation ends it.
+    /// </para>
+    /// </remarks>
+    [Fact]
+    public async Task TheFirstPassRunsAtStart_RatherThanOnADelay()
+    {
+        channel.Available = new AvailableUpdate("1.3.0");
+
+        var updates = Build();
+        await using var _ = updates.ConfigureAwait(false);
+
+        updates.Start();
+
+        while (updates.State is not UpdateState.Ready)
+        {
+            Token.ThrowIfCancellationRequested();
+
+            await Task.Yield();
+        }
+
+        channel.Checks.ShouldBe(1);
+        updates.ReadyVersion.ShouldBe("1.3.0");
+    }
+
+    /// <remarks>
+    /// Started and disposed with nothing in between, which since the first pass stopped waiting two minutes
+    /// is a race rather than a formality: the loop may be anywhere between its yield and a finished check
+    /// when the cancellation lands. What is asserted is what matters either way — that disposing returns,
+    /// rather than waiting on a pass that will never be allowed to finish.
+    /// </remarks>
     [Fact]
     public async Task DisposingStopsTheLoop()
     {

tests/DodoSSH.Client.Ssh.Tests/SshServerFixture.cs

@@ -1,4 +1,6 @@
+using System.Net.Sockets;
 using System.Security.Cryptography;
+using System.Text;
 using DotNet.Testcontainers.Builders;
 using DotNet.Testcontainers.Containers;
 using Xunit;
@@ -40,6 +42,21 @@ public sealed class SshServerFixture : IAsyncLifetime
 
     private const int SshPort = 2222;
 
+    /// <summary>
+    /// How many connections in a row the server has to answer before this fixture calls it ready.
+    /// </summary>
+    /// <remarks>
+    /// Twenty-five, and the number is measured rather than picked. Probing a fresh container 200 times with
+    /// penalties left at the image's default, the first <c>Not allowed at this time</c> came back at probe
+    /// 18 and 183 of the 200 were refused; with <c>PerSourcePenalties no</c> applied, none of 200 were. Ten
+    /// was tried first and is useless — it sits below the threshold, so the guard passed happily against a
+    /// server that was still penalising. See <see cref="WaitUntilServingAsync"/>.
+    /// </remarks>
+    private const int RequiredStreak = 25;
+
+    /// <summary>How long to keep trying before giving up on the server entirely.</summary>
+    private static readonly TimeSpan ReadyTimeout = TimeSpan.FromSeconds(60);
+
     private readonly SemaphoreSlim sftpGate = new(1, 1);
 
     private IContainer? container;
@@ -80,101 +97,94 @@ public sealed class SshServerFixture : IAsyncLifetime
             .Build();
 
         await container.StartAsync();
-        await AllowTcpForwardingAsync();
+        await ReconfigureAsync();
+        await WaitUntilServingAsync();
     }
 
     /// <summary>
-    /// Lets this server open the direct-tcpip channels a forward is made of.
+    /// Turns off the hardening this suite trips over, and makes the running server re-read its config.
     /// </summary>
     /// <remarks>
     /// <para>
-    /// ◆ <b>The image ships <c>AllowTcpForwarding no</c>, and nothing says so at the point it bites.</b> A
+    /// ◆ <b><c>PerSourcePenalties no</c> is the fix for the flake this suite had for months, and the other
-    /// dynamic forward starts perfectly happily — it is a local listener, and opening it asks the server
+    /// two settings here are not.</b> OpenSSH 9.8 added per-source penalties and 10.x has them on by
-    /// nothing — and then every connection through it is refused when the channel is opened. SSH.NET
+    /// default; this image runs 10.3. A source address that keeps disconnecting without authenticating is
-    /// reports that as <c>SOCKS5: General failure</c> from the proxy, which names neither the server nor
+    /// penalised, and while the penalty holds every connection from it is answered with the clear-text line
-    /// the setting, and is what the first run of <c>LoopbackProxyTests</c> collected.
+    /// <c>Not allowed at this time</c> and then closed.
     /// </para>
     /// <para>
-    /// Patched after start rather than baked in, because the image's entrypoint writes its configuration
+    /// <b>This suite generates exactly that traffic, by design.</b> This client's first contact with an
-    /// itself on every boot — a mounted file would be overwritten before sshd read it. sshd re-reads on
+    /// unknown host is a connection deliberately refused at the host key — which is a disconnect with no
-    /// <c>SIGHUP</c> and applies the result to connections made after that, and the readiness wait has
+    /// authentication attempt — and several tests do nothing else:
-    /// already run, so nothing here races the boot.
+    /// <c>RefusingTheHostKey_AbortsTheConnection</c>, <c>AnUntrustedHost_IsRefusedExactlyAsAShellWouldBe</c>,
+    /// and every helper that learns a host key by being turned away first. Enough of them close together and
+    /// sshd stops talking to the test host altogether, for a while, and then starts again.
+    /// </para>
+    /// <para>
+    /// From the client that is <c>SshConnectionException: The connection was closed by the remote host</c>
+    /// within milliseconds — no banner, nothing to say which of the many reasons it was. It hits whichever
+    /// class is running when the penalty lands and spares the rest, which is why it read as random and why
+    /// the class it hit lost <em>every</em> connection it made rather than a random few. The one test in that
+    /// class that expects a refusal passed throughout, for the wrong reason.
+    /// </para>
+    /// <para>
+    /// ◆ <b>Two earlier diagnoses were wrong, and are recorded here so they are not tried again.</b>
+    /// <c>MaxStartups</c> was blamed on the reasoning that xUnit runs test classes in parallel, so ten
+    /// unauthenticated connections would be in flight at once — but every class that touches this server
+    /// shares <see cref="SshCollection"/>, and xUnit's unit of parallelism is the collection, so they run one
+    /// after another and never have more than a connection or two open. The reload window was blamed next,
+    /// and a wait for the banner to answer was written and removed as unproven; it was unproven because the
+    /// banner does answer, right up until the penalty lands.
+    /// </para>
+    /// <para>
+    /// The line is appended rather than replaced in place, unlike the two below it, because the image's
+    /// config does not mention the keyword at all — there is no line to replace, and sshd takes the first
+    /// value it finds for a keyword that appears more than once.
+    /// </para>
+    /// <para>
+    /// ◆ <b><c>AllowTcpForwarding</c> is what a dynamic forward needs</b>, and the image ships it off as
+    /// hardening. Without it a forward opens perfectly happily — a local listener asks the server nothing —
+    /// and then every connection through it is refused when the channel is opened. SSH.NET reports that as
+    /// <c>SOCKS5: General failure</c>, which names neither the server nor the setting, and is what the first
+    /// run of <c>LoopbackProxyTests</c> collected. That suite is also the alarm if this method ever silently
+    /// stops working.
+    /// </para>
+    /// <para>
+    /// <c>MaxStartups</c> is raised for the reason it should have been in the first place rather than as a
+    /// fix for anything: the compiled-in default refuses connections at random past ten unauthenticated ones
+    /// in flight, and a throttle is hardening a test server has no business reproducing. It is kept, not
+    /// because it was ever shown to matter here, but because removing it would be a second change riding
+    /// along with this one.
+    /// </para>
+    /// <para>
+    /// Both are replaced in place rather than appended, because sshd_config takes the <em>first</em> value
+    /// it finds for a keyword: an appended line would be dead the day the image ships an uncommented one of
+    /// its own.
     /// </para>
     /// <para>
     /// ◆ <b><c>/config/sshd/sshd_config</c>, and there are two.</b> The image also carries
-    /// <c>/etc/ssh/sshd_config</c>, which looks like the file to patch, reads identically, and is not the
+    /// <c>/etc/ssh/sshd_config</c>, which looks like the file to patch, reads identically, and is not the one
-    /// one the running server was started with — patching it changes the text and nothing else, which is a
+    /// the running server was started with — patching it changes the text and nothing else, which is a fix
-    /// fix that appears to work and leaves the failure exactly where it was. Measured with <c>find</c>
+    /// that appears to work and leaves the failure exactly where it was.
-    /// rather than assumed, after the first version of this method did precisely that.
     /// </para>
     /// <para>
-    /// It is on for the whole assembly rather than for the one test that needs it. Forwarding is off in
+    /// ◆ <b>Patched after boot and reloaded, rather than injected before it — which was tried and does not
-    /// this image as hardening, not as a behaviour worth reproducing: nothing else here opens a channel of
+    /// work.</b> This image family runs <c>/custom-cont-init.d</c> scripts, which look like the right hook
-    /// any kind, so allowing it changes what exactly one suite can do and what none of the others see.
+    /// and are not: the container's own log puts <c>sshd is listening on port 2222</c> <em>before</em>
-    /// </para>
+    /// <c>[custom-init] Files found, executing</c>, so a script there edits a file the running server has
-    /// <para>
+    /// already read. It leaves a config that greps correctly and a server behaving as though it had never
-    /// ◆ <b><c>MaxStartups</c> is raised here too, against a flake this suite has and that this change is
+    /// been touched — the same trap as the wrong file, one layer up. Measured from the log, after a version
-    /// a mitigation for rather than a proven cure.</b> The distinction is stated because the evidence
+    /// of this fixture did exactly that and failed twenty-eight tests.
-    /// stops short of the claim, and a later reader deserves to know which.
-    /// </para>
-    /// <para>
-    /// What is established: sshd's compiled-in default is <c>10:30:100</c> — past ten
-    /// <em>unauthenticated</em> connections in flight it refuses new ones at random, thirty percent of the
-    /// time, rising to always at a hundred — and the image ships the line commented out, so that default
-    /// was what ran. xUnit runs test classes in parallel and most classes here open a connection, so ten
-    /// in flight is reachable in the opening seconds. A refused connection presents to the client as
-    /// <c>SshConnectionException: The connection was closed by the remote host</c> within tens of
-    /// milliseconds, on whichever test connects at the wrong moment — which is exactly the observed
-    /// failure, seen in CI and reproduced locally.
-    /// </para>
-    /// <para>
-    /// What is <em>not</em> established is that this limit is the only cause, because the flake rate could
-    /// not be measured reliably. On the development machine the identical unmodified suite ran 85/85 clean
-    /// and, an hour later, failed 13 runs out of 15 — Docker throughput on that host swings far enough to
-    /// swamp the effect being measured. Any before/after comparison taken there is noise, and two were,
-    /// before that was noticed.
-    /// </para>
-    /// <para>
-    /// It is committed anyway, on the narrower argument that it is right regardless: a connection throttle
-    /// is hardening this suite has no interest in reproducing. It exists to test an SSH client, not to
-    /// survive a rate limit, and a test server that drops connections at random is a bad test server
-    /// whether or not it is the cause of this particular flake.
-    /// </para>
-    /// <para>
-    /// <b>Not fixed by serialising the suite</b>, which would have hidden it and cost the parallelism, and
-    /// not by retrying the connect, which would have made the client's own reconnect behaviour untestable
-    /// by burying it in the fixture. The limit is a property of a hardened server that this suite has no
-    /// interest in reproducing — it exists to test an SSH client, not to survive a throttle.
-    /// </para>
-    /// <para>
-    /// Replaced in place rather than appended, because sshd_config takes the <em>first</em> value it finds
-    /// for a keyword: an appended line would be dead the day the image ships an uncommented one of its own.
-    /// </para>
-    /// <para>
-    /// ◆ <b>The reload window is the other candidate, and it is deliberately not guarded against.</b>
-    /// <c>SIGHUP</c> makes sshd close its listeners and re-execute itself, and <c>pkill</c> returns when
-    /// the signal is delivered rather than when that has finished — so in principle a connection made
-    /// immediately afterwards is refused, producing this same exception. A wait that opened connections
-    /// until the server answered with its banner three times running was written, and then removed: it
-    /// could not be shown to change anything either, and a fixture carrying two unproven fixes for one
-    /// symptom is worse than one, because the next person has to disprove both.
-    /// </para>
-    /// <para>
-    /// If this flake returns, that is the next thing to try. Two things to know before trying it: the two
-    /// causes are indistinguishable from the client, so a fix can only be judged by a repeat run and never
-    /// by whether the next run passes — and the repeat run has to happen somewhere with stable Docker
-    /// throughput, which the development machine is not. Better still, make sshd say why: raise its
-    /// <c>LogLevel</c> here, disable Ryuk so the container outlives the run, and read
-    /// <c>docker logs</c>. A <c>MaxStartups</c> refusal names itself there; a reload does not.
     /// </para>
     /// </remarks>
-    private async Task AllowTcpForwardingAsync()
+    private async Task ReconfigureAsync()
     {
         var result = await container!.ExecAsync([
             "sh",
             "-c",
             "sed -i 's/^AllowTcpForwarding no/AllowTcpForwarding yes/' /config/sshd/sshd_config"
                 + " && sed -i 's/^#*MaxStartups .*/MaxStartups 200/' /config/sshd/sshd_config"
+                + " && printf '\\nPerSourcePenalties no\\n' >> /config/sshd/sshd_config"
                 + " && pkill -HUP sshd",
         ]);
 
@@ -183,7 +193,107 @@ public sealed class SshServerFixture : IAsyncLifetime
             throw new InvalidOperationException(
                 $"Could not reconfigure the test server: {result.Stderr}");
         }
+    }
 
+    /// <summary>
+    /// Blocks until the server answers <see cref="RequiredStreak"/> connections in a row with its banner.
+    /// </summary>
+    /// <remarks>
+    /// <para>
+    /// ◆ <b>This is a guard rather than a wait, and what it guards against is
+    /// <c>PerSourcePenalties</c> coming back.</b> Reconfiguring above turns it off; this proves it is off,
+    /// immediately and by name, instead of letting the suite discover it later as an unrelated-looking
+    /// failure in whichever class happened to be running.
+    /// </para>
+    /// <para>
+    /// <b>Consecutive, and deliberately with no pause between them.</b> Each probe opens a connection, reads
+    /// the identification string and disconnects without authenticating — which is exactly the shape of
+    /// connection <c>PerSourcePenalties</c> punishes, and exactly what this suite does all day: a first
+    /// contact with an unknown host is a connection this client deliberately refuses at the host key.
+    /// <see cref="RequiredStreak"/> back to back is therefore not a soak test, it is the specific
+    /// provocation, sized above the measured threshold on purpose, and it costs well under a second when the
+    /// setting is off.
+    /// </para>
+    /// <para>
+    /// It is also the one check that can tell a listening socket from a running server. The container's own
+    /// readiness — a log line and <c>netstat</c> showing <c>:2222</c> — passes on a container whose sshd has
+    /// gone: the socket is published by a host-side proxy that accepts before it has anything to forward to,
+    /// so a dead server presents as a connection accepted and closed rather than as one refused.
+    /// </para>
+    /// <para>
+    /// Probed from the host rather than with <c>docker exec</c>, deliberately: that is the path the tests
+    /// take, proxy included, and penalties are counted per source address — from inside the container the
+    /// source would be the loopback rather than the address every test connects from.
+    /// </para>
+    /// </remarks>
+    private async Task WaitUntilServingAsync()
+    {
+        // TimeProvider.System rather than DateTimeOffset.UtcNow, which this repository bans so that time can
+        // be faked — and rather than a fake, because what is being waited on is a real container starting.
+        var deadline = TimeProvider.System.GetUtcNow() + ReadyTimeout;
+        var streak = 0;
+        var last = "no probe ran";
+
+        while (streak < RequiredStreak)
+        {
+            if (TimeProvider.System.GetUtcNow() >= deadline)
+            {
+                throw new InvalidOperationException(
+                    $"The test server did not answer {RequiredStreak} connections in a row within "
+                    + $"{ReadyTimeout}. The last probe said: {last}. If it says \"Not allowed at this "
+                    + "time\", sshd is penalising this source address and PerSourcePenalties is no longer "
+                    + "being turned off — see ReconfigureAsync.");
+            }
+
+            var (answered, what) = await ProbeAsync();
+            last = what;
+
+            if (answered)
+            {
+                streak++;
+                continue;
+            }
+
+            // Only pause when it is not working. Back-to-back probes are the point while they succeed;
+            // hammering a server that has not finished starting is just noise.
+            streak = 0;
+            await Task.Delay(TimeSpan.FromMilliseconds(200));
+        }
+    }
+
+    /// <summary>Opens a socket and reads far enough to see OpenSSH's identification string.</summary>
+    /// <remarks>
+    /// The description comes back with the answer because the interesting failures are not exceptions. A
+    /// penalised source is told <c>Not allowed at this time</c> in clear text before the socket closes, and
+    /// a suite that only knew "no banner" would have to go and find that out again — which is what happened
+    /// the first time, at some length.
+    /// </remarks>
+    private async Task<(bool Answered, string What)> ProbeAsync()
+    {
+        try
+        {
+            using var probe = new TcpClient();
+            using var timeout = new CancellationTokenSource(TimeSpan.FromSeconds(5));
+
+            await probe.ConnectAsync(Host, Port, timeout.Token);
+
+            var buffer = new byte[64];
+            var read = await probe.GetStream().ReadAtLeastAsync(
+                buffer, 4, throwOnEndOfStream: false, timeout.Token);
+
+            var answered = read >= 4 && "SSH-"u8.SequenceEqual(buffer.AsSpan(0, 4));
+
+            return (
+                answered,
+                answered
+                    ? "SSH-"
+                    : $"{read} bytes: "
+                        + Encoding.ASCII.GetString(buffer, 0, Math.Max(read, 0)).ReplaceLineEndings(" "));
+        }
+        catch (Exception exception) when (exception is SocketException or OperationCanceledException or IOException)
+        {
+            return (false, $"{exception.GetType().Name}: {exception.Message}");
+        }
     }
 
     /// <summary>
@@ -225,12 +335,17 @@ public sealed class SshServerFixture : IAsyncLifetime
     /// </summary>
     /// <remarks>
     /// <para>
-    /// Shared rather than opened per test, and that is a limit of the server rather than an optimisation.
+    /// Shared rather than opened per test. This was once explained as a way of staying under the server's
-    /// sshd's <c>MaxStartups</c> drops connections at random once enough are part-way through a handshake,
+    /// <c>MaxStartups</c> throttle, on the belief that the suite ran its classes in parallel and made two
-    /// and this client's first contact with an unknown host is a connection deliberately <em>refused</em> at
+    /// handshakes per test — this client's first contact with an unknown host is a connection deliberately
-    /// the host key — so a suite that opened its own session per test made two handshakes per test and
+    /// <em>refused</em> at the host key, so every session costs two. The parallelism was not real: every
-    /// pushed the whole assembly over the threshold. What that looks like is unrelated tests failing with
+    /// class here shares one collection and xUnit runs collections, not classes, in parallel. See
-    /// "the connection was closed by the remote host", a different few each run.
+    /// <see cref="WaitUntilServingAsync"/>, which is where that mistake was found and what the failure it
+    /// was blamed for turned out to be.
+    /// </para>
+    /// <para>
+    /// It stays shared regardless, on the plainer argument: one session is enough, and a handshake per test
+    /// would be seconds of the suite's runtime spent proving nothing this file has not already proved.
     /// </para>
     /// <para>
     /// Safe to share because an SFTP session holds no per-test state: every test here works in a directory