Stagecoach 0.8.2 - stop inventing Arc SSH prerequisites

Readiness demanded a WindowsOpenSSH extension, and 0.8.1 replaced that with a Microsoft.HybridConnectivity endpoint. Both were wrong, and the second could never have worked: verified against a live tenant, Resource Graph does not return hybrid connectivity endpoints at all -- the type is absent from the inventory of a resource group that demonstrably has one. The check could not pass for anybody.

A connected Arc agent is the whole prerequisite Resource Graph can actually speak to. Recent Windows Server ships OpenSSH itself, so the extension proves nothing either. Guessing at reachability from data that cannot describe it is worse than not guessing: the connection attempt is the real test, and a helper that dies reports what the Azure CLI said.

Found while fixing it: the agent-state test was a substring match, and Disconnected contains connected -- so a machine whose Arc agent had dropped was reported as reachable. It is an equality check now.

Build clean, 92 tests, formatting clean.

Stagecoach 0.8.1 - Arc SSH readiness, and closing the selected machine

Readiness required a WindowsOpenSSH Arc extension, so a machine that connects perfectly well from a terminal was reported as Windows OpenSSH/Arc SSH readiness was not detected.

What az ssh arc actually connects through is the machine's Microsoft.HybridConnectivity endpoint. Recent Windows Server ships OpenSSH itself, so that extension is one way to arrive at SSH and never a requirement.

Confirmed against a real machine: no WindowsOpenSSH extension, a provisioned default hybrid connectivity endpoint, and it connects by hand. Discovery already collected those endpoints and simply never looked at them. It does now, and where no endpoint is found the wording no longer claims to know that SSH is missing.

Selecting a machine also opened a panel with no way to put it away, so the table stayed shrunk for as long as anything was selected. It has a Close button.

Build clean, 91 tests, formatting clean.

Stagecoach 0.8.0 - one instance, and an installer that can replace it

One Stagecoach per Windows session — and an installer that can actually replace it.

Five copies were running at once

Nothing stopped a second launch, and there is no reason to want one. Two copies open the same encrypted database, each runs its own background sync, and each owns helper processes the other cannot see — so closing one can leave live sessions behind that nothing is tracking any more.

Launching Stagecoach again now brings the window you already have forward, whether that launch came from the Start menu, the desktop, or the installer's finish dialog.

The guard is scoped to the logon session rather than the whole machine. On a host several people are signed in to at once — a terminal server, which is exactly where this gets used — each of them is entitled to their own instance and their own estate.

If the guard itself cannot be created, Stagecoach starts anyway. Refusing to run because a synchronisation object could not be opened would be a worse failure than two windows.

The installer could not close the application

Asking politely was never enough: Stagecoach deliberately refuses an ordinary close while sessions are running, hiding to the notification area instead — so the close message the installer sent was cancelled by the application itself. Copies survived upgrades and carried on running the old binary.

The installer now asks and then ends the process, which is what replacing a running executable requires. The in-app update path still warns about live sessions before any of that happens.

Verified on a real machine: five instances before the install, none after.

Install

Download Stagecoach-0.8.0-win-x64.msi, or use Settings → Software updates. Verify against the .sha256 sidecar.

Verified

Build clean, 89 tests, formatting clean.

Stagecoach 0.7.9 - the machine table fills the window and scrolls itself

The machine table now uses the window, and nothing draws on top of a row.

What was wrong

The Machines screen was one long scrolling column, and the table inside it grew to its content with no scrolling of its own. Three things followed from that:

• The table did not use the window. Making the window taller added empty space below the table rather than showing more machines.
• A long estate pushed everything else off the screen, because the only scroll region was the whole page.
• The horizontal scrollbar sat on top of the last row instead of beneath it — and with a single machine, on top of the only row.

What it does now

The screen is three bands: what is above the table, the table, and what is below it. Only the table takes the leftover height.

• It grows and shrinks with the window.
• When the estate is longer than the space, the table scrolls inside itself — the rest of the screen stays put.
• Rows are inset from the vertical scrollbar, and the horizontal scrollbar has its own reserved strip, so neither draws over a machine.
• The selected-machine and pending-change panels are capped and scroll, so selecting a machine can never squeeze the table it was selected from.

Install

Download Stagecoach-0.7.9-win-x64.msi, or use Settings → Software updates. Verify against the .sha256 sidecar.

Verified

Build clean, 86 tests, formatting clean.

Stagecoach 0.7.8 - machines in other tenants were invisible

Machines in other tenants were invisible. One account, fifty subscriptions, one machine shown.

What was wrong

Azure Resource Graph answers only for the tenant the current token belongs to. Subscriptions from any other tenant are dropped from the request — and dropped silently when they are mixed in with valid ones.

Discovery sent every selected subscription in a single request. So everything outside whichever tenant happened to be active was simply never looked at.

Proven, not assumed

On a real account with access across several tenants:

• A Resource Graph query naming a subscription in another tenant returned nothing, reporting NoValidSubscriptionsInQueryRequest.
• Selecting a subscription in that tenant first and running the identical query returned all four machines in it.
• ARM had been listing those machines the whole time — only Resource Graph could not see them.

That is why the machine list showed one machine when the account could reach several.

What happens now

Discovery groups the selected subscriptions by tenant and, for each tenant, selects a subscription there so the Azure CLI holds a token for it before querying. Every tenant is scanned, not just the active one.

A tenant that fails no longer costs you the machines in the others: it is reported as a warning and the scan carries on.

Install

Download Stagecoach-0.7.8-win-x64.msi, or use Settings → Software updates. Verify against the .sha256 sidecar.

Verified

Build clean, 86 tests, formatting clean. Two new tests assert that each tenant is selected and queried separately, that a single request never mixes subscriptions from two tenants, and that one tenant failing does not lose the rest.

Stagecoach 0.7.7 - the sign-in loop on an Entra joined machine

The sign-in loop on an Entra joined machine, fixed.

What was happening

On a Microsoft Entra joined machine the signed-in Windows account is a cloud account, and LogonUser cannot validate one of those with a password. Windows Hello cannot prompt inside a remote session either.

So over RDP the unlock screen asked for Windows credentials, the correct password failed exactly like a wrong one would, and the previous release — which had stopped treating a failed check as a way in — then refused to offer any way forward.

Prompt, reject, back to the start. Every time.

That hardening was right for a genuine refusal and wrong here: nothing was refused, because nothing could be asked in the first place.

What happens now

A cloud account is recognised. The prompt that could only ever fail is not shown at all, and the screen says plainly that Windows cannot verify anyone in this session and that you are already signed in as the owner of the installation.

Continuing is then the way in, and it is the obvious button rather than a footnote under a failure.

Where a check is possible — Windows Hello, or a local or domain account — it still happens, and a wrong password still gets nobody in.

Taking ownership through Use this Windows account instead had the same dead end, and the same fix.

Install

Download Stagecoach-0.7.7-win-x64.msi, or use Settings → Software updates. Verify against the .sha256 sidecar.

Verified

Build clean, 84 tests, formatting clean. The account type was confirmed on a real Entra joined machine: authentication package CloudAP, security identifier in the S-1-12-1-… form.

Stagecoach 0.7.6 - the repository, not just the source

The rest of the repository, audited — not just the application source.

The installer was never checksummed

scripts/Package.ps1 built the MSI and left it wherever WiX put it. It was never copied beside the archive in artifacts/, and it never got a .sha256 sidecar. Only the ZIP did.

So the one artifact the download page tells people to verify had nothing to verify it against, unless somebody produced the hash by hand — which is exactly what had been happening for every release.

Packaging now copies the installer into artifacts/, writes its checksum, and fails loudly if the installer was not produced at all. This release was built with the fixed script and both sidecars appeared on their own.

Everything else in the repository

The build, run and shortcut scripts, the WiX package definition, the documentation workflow and every project file were read. They are sound:

• The scripts all set Set-StrictMode -Version Latest and $ErrorActionPreference = 'Stop', check $LASTEXITCODE after every dotnet call, and validate their parameters.
• The installer carries its icon in Add/Remove Programs, closes a running Stagecoach before an upgrade rather than failing on locked files, and offers a real install interface.
• The documentation workflow runs with read-only contents permission, does not persist credentials, and grants write access only to the deploy job.

Install

Download Stagecoach-0.7.6-win-x64.msi, or use Settings → Software updates. Verify against the .sha256 sidecar — which now exists because the build produced it.

Verified

Build clean, 84 tests, formatting clean.

Stagecoach 0.7.5 - the last of the codebase, audited

The last of the codebase, read line by line. Six more defects.

Actions that failed silently

Toggling a tenant, a subscription or a favourite, pinning an account to a machine, stopping a session and saving settings all called storage directly from an asynchronous command with no error handling at all. A failure became an unobserved exception: the row did not change, nothing was said, and nothing was recorded.

All of them now report the failure and record it, without taking the busy gate — they are quick actions and should not block the application.

Two operations could run at once

The update check set the busy flag itself instead of going through the gate that everything else uses. Finishing the check therefore cleared the gate while another operation was still running, re-enabling every button underneath it.

Cancelling Quick Connect left things behind

It discarded nothing. The throwaway Azure profile, with its token cache, stayed on disk until Quick Connect happened to be opened again, and the typed password stayed in memory.

An abandoned one-off connection must leave less behind than one that went ahead, not more. It now clears both.

First-run setup could crash at the final click

Writing the owner record caught only one kind of failure. A redirected folder, antivirus, or a permission change would crash the application outright at the last step of setup — with no record of why. The passphrase removal window had the same shape, and it is the only way past that screen.

Both now report what happened.

One more way to lose the application

The notification area's Sync now is an async void handler with no catch — anything escaping it would end the process, with sessions running unattended.

Install

Download Stagecoach-0.7.5-win-x64.msi, or use Settings → Software updates. Verify against the .sha256 sidecar. Not yet Authenticode signed, so SmartScreen will warn.

Verified

Build clean, 84 tests, formatting clean.

Stagecoach 0.7.4 - the rest of the codebase, audited

The rest of the codebase, audited. Six more defects.

Closing the application could hang

The activity entry written on close was waited on from the interface thread, and the write resumes on that same thread — a deadlock, introduced with that entry two releases ago. It now runs off the interface thread with a bounded wait. A missed entry is better than a window that will not close.

Adding an account could only time out

Adding or reauthenticating an Entra account had no device-code fallback. A browser sign-in that never appears cannot be told apart from one still being worked through, so it could only end in a five-minute wait and a message suggesting the other button — which is exactly what one operator's log showed.

It now falls back on its own, as the owner sign-in already did. Reauthentication also rewrites the Azure CLI profile settings first, because a profile created by an older version has none of them.

Every remaining positional query is gone

Eleven statements across six tables now name their columns. This is the shape that broke the machine list on every upgraded database — reading and writing by position, where a column added later sits in a different place — and it was still present everywhere else. There is now none left in the codebase.

Two ways the application could be killed outright

The background sync timer is an async void handler: an exception escaping it would have taken the process down, with live sessions running. The session watchers are started without being awaited and could raise unobserved exceptions the same way. Both are contained.

Install

Download Stagecoach-0.7.4-win-x64.msi, or use Settings → Software updates. Verify against the .sha256 sidecar. Not yet Authenticode signed, so SmartScreen will warn.

Verified

Build clean, 84 tests, formatting clean.

Stagecoach 0.7.3 - audit of the connection and sign-in paths

A line-by-line audit of the connection and sign-in paths. Three more defects, and the Bastion failure verified on a real machine rather than reasoned about.

A finished session held on to a credential

When a connection helper exited, the session state was updated and nothing else happened. The session stayed in the registry and was never disposed — so the staged Remote Desktop credential was never removed from Windows Credential Manager, for the rest of the application's life.

This affected every route that has a helper and no client process to watch: native Bastion RDP and Arc RDP. Routes with a client process were always cleaned up correctly. A finished session now releases what it holds, exactly as stopping one by hand does.

Failed attempts accumulated

A connection that failed to launch was disposed but left in the session registry, so every failed attempt stayed in the session list until the application closed.

The Azure CLI can no longer stop to ask a question

The settings that stop the CLI prompting are now applied as environment variables in the one place every invocation passes through, not only written into each profile. A profile created by an older version, or one not configured yet, can no longer hang on a question that nobody can see.

Verified, not assumed. With a fresh extension directory and no environment variables:

az network bastion --help   ->  exit 1, "EOF when reading a line"

With the variables set:

az network bastion --help   ->  exit 0, help printed

The first is exactly the failure behind "it says connected but no Remote Desktop opens".

Install

Download Stagecoach-0.7.3-win-x64.msi, or use Settings → Software updates. Verify against the .sha256 sidecar. Not yet Authenticode signed, so SmartScreen will warn.

Verified

Build clean, 84 tests, formatting clean.