v1.1.11

Install

Pick your platform on the website,
or take a file below. Every download is listed in SHA256SUMS.txt.

Already running it? It updates itself: open the window and choose Update now,
or run gcloud-dot upgrade.

What changed

Say where the product stands with Windows hardening rules

A Defender attack surface reduction rule blocked gcloud-dot-tray.exe being
started, and the alert looked like the product misbehaving. It was not: the
parent was WmiPrvSE.exe, because this project's own remote test harness started
the tray over SSH with Invoke-CimMethod on Win32_Process, and blocking process
creation that originates from WMI is precisely what that rule is for. One such
event exists in the machine's entire Defender history, timestamped to the
harness session; the startup shortcut route users actually take has never
tripped anything across multiple reboots.

An earlier session had already collided with the same rule without recognising
it: Win32_Process.Create returning 2 was read as a WMI quirk and worked around
with schtasks. It was this block.

SECURITY.md now states the position outright: nothing shipped creates a
process via WMI or PSExec, nothing uses -EncodedCommand or -WindowStyle
Hidden, and every way the tray starts gives it an ordinary parent. The one
shipped use of WMI at all is a read-only Get-CimInstance query during legacy
migration, which creates nothing.

Notice a dead tray icon and put a new one up

Explorer crashed on the Windows machine, an access violation in a shell DLL
four days into the tray's six day run, and from then on the icon took clicks
and did nothing: no menu, no window, no way to quit. The process behind it was
demonstrably healthy the whole time, answering its five second tick and
consuming a quit request the moment one was written. The user's entirely
reasonable read was "the app is stuck".

The library re-registers the icon when the shell broadcasts TaskbarCreated,
but after a crash restart that is not always the whole story, so the app stops
assuming. Once a tick it pushes the tooltip it is already showing, one cheap
shell message whose reply says whether the icon still exists, and on any error
it rebuilds the tray from scratch, menu and all. Worst case after a shell
crash is now five seconds without an icon.

Debugging this took an evening of Defender timestamps and file mtimes, because
a GUI process has no stderr anyone can see. The tray now keeps a small log
beside its state file, capped and trimmed, noting startup, icon rebuilds,
failed window opens, sign in failures, and update outcomes. tray.log next to
state.json.

Two more findings from the same post mortem. The staging directory still held
the previous installer, because a Windows tray upgrading itself is killed by
that installer partway through apply and the cleanup at the end never runs:
startup now sweeps it, and the tray no longer waits to be killed at all. It
starts the installer detached, reports the handover, and lets the installer
replace the files and start a fresh tray, which is what already happens on a
machine where the upgrade goes through the command line. The command line
itself keeps its synchronous path, since the installer does not kill it.

1.1.11: the tray survives a shell crash

Full changelog: v1.1.10...v1.1.11