Summary
The Plank dock that ships with the default portabledesktop session draws launcher icons, but clicking them is a silent no-op on any host where dbus-launch is not on PATH. The dock therefore appears functional but is purely cosmetic on those hosts.
A "portable" desktop binary that requires the host to supply dbus-launch for a core UI feature is, in practice, not portable — every consuming image hits this until they happen to install a package that pulls in dbus-x11 transitively.
Reproduction
Observed on a fresh Coder Agents workspace using codercom/oss-dogfood:latest (which does not ship dbus-x11), running the default desktop served by portabledesktop up.
which dbus-launch → not found.- Open the noVNC viewer; the Plank dock renders with Chrome (and other discovered apps) and tooltips work on hover.
- Click the Chrome dock icon.
- Expected: Chrome launches.
- Actual: nothing happens.
dock.log shows no spawn lines for the launch. No error surfaces in the UI.
After sudo apt-get install -y dbus-x11 and restarting Plank (no other changes), clicks immediately begin spawning the target binaries — dock.log shows the new child PIDs and Plank's GIO launch path completes. (Post-launch crashes seen with Chrome and Meld in this environment are separate, unrelated issues — Chrome crashpad/ptrace and Meld AT-SPI — and reproduce when launching the same binaries directly outside Plank.)
Root cause
Plank-reloaded launches desktop entries via GLib/GIO (GAppInfo.launch_default_for_uri() and friends), which dispatches over the session D-Bus. When DBUS_SESSION_BUS_ADDRESS is unset, GIO's documented fallback is to autolaunch a session bus by exec'ing dbus-launch from PATH.
The portabledesktop runtime:
- Builds Plank with
-Denable-dbusmenu=no and strips dbus-1.0 from the Nix runtime tree (flake.nix).
BuildEnv in pd/internal/desktop/env.go does not set DBUS_SESSION_BUS_ADDRESS or otherwise provision a session bus.StartDock in pd/internal/desktop/dock.go launches Plank with the env from BuildEnv only.
So Plank inherits a PATH that, on a stock image without dbus-x11, has no dbus-launch. GIO's autolaunch silently fails and the launch RPC never reaches a handler. The icon-drawing path doesn't need the bus, which is why this presents as "icon visible, click does nothing."
Suggested fixes (in order of preference)
- Wrap Plank in
dbus-run-session inside StartDock so each session gets its own bus deterministically, regardless of host.
- Bundle
dbus-launch / dbus-daemon in the embedded Nix runtime so the binary stays self-contained per its README ("no containers or display servers to configure").
- At minimum, detect the missing bus at dock startup and log a clear error to
dock.log (and ideally surface it in the dock startup error path) instead of silently producing a cosmetic dock.
Happy to send a PR for option 1 if that's the preferred direction.
Impact
- Affects every host image that doesn't already pull in
dbus-x11 (or equivalent).
- Currently silent: there is no error in
dock.log, viewer, or CLI output, so it presents to users as "the dock is broken" rather than "a dependency is missing."
- Workaround for image maintainers: install
dbus-x11. This was verified end-to-end on the dogfood image.
Filed on behalf of @tracyjohnsonux by a Coder Agents-generated agent.
Summary
The Plank dock that ships with the default portabledesktop session draws launcher icons, but clicking them is a silent no-op on any host where
dbus-launchis not onPATH. The dock therefore appears functional but is purely cosmetic on those hosts.A "portable" desktop binary that requires the host to supply
dbus-launchfor a core UI feature is, in practice, not portable — every consuming image hits this until they happen to install a package that pulls indbus-x11transitively.Reproduction
Observed on a fresh Coder Agents workspace using
codercom/oss-dogfood:latest(which does not shipdbus-x11), running the default desktop served byportabledesktop up.which dbus-launch→ not found.dock.logshows no spawn lines for the launch. No error surfaces in the UI.After
sudo apt-get install -y dbus-x11and restarting Plank (no other changes), clicks immediately begin spawning the target binaries —dock.logshows the new child PIDs and Plank's GIO launch path completes. (Post-launch crashes seen with Chrome and Meld in this environment are separate, unrelated issues — Chrome crashpad/ptrace and Meld AT-SPI — and reproduce when launching the same binaries directly outside Plank.)Root cause
Plank-reloaded launches desktop entries via GLib/GIO (
GAppInfo.launch_default_for_uri()and friends), which dispatches over the session D-Bus. WhenDBUS_SESSION_BUS_ADDRESSis unset, GIO's documented fallback is to autolaunch a session bus by exec'ingdbus-launchfromPATH.The portabledesktop runtime:
-Denable-dbusmenu=noand stripsdbus-1.0from the Nix runtime tree (flake.nix).BuildEnvinpd/internal/desktop/env.godoes not setDBUS_SESSION_BUS_ADDRESSor otherwise provision a session bus.StartDockinpd/internal/desktop/dock.golaunches Plank with the env fromBuildEnvonly.So Plank inherits a
PATHthat, on a stock image withoutdbus-x11, has nodbus-launch. GIO's autolaunch silently fails and the launch RPC never reaches a handler. The icon-drawing path doesn't need the bus, which is why this presents as "icon visible, click does nothing."Suggested fixes (in order of preference)
dbus-run-sessioninsideStartDockso each session gets its own bus deterministically, regardless of host.dbus-launch/dbus-daemonin the embedded Nix runtime so the binary stays self-contained per its README ("no containers or display servers to configure").dock.log(and ideally surface it in the dock startup error path) instead of silently producing a cosmetic dock.Happy to send a PR for option 1 if that's the preferred direction.
Impact
dbus-x11(or equivalent).dock.log, viewer, or CLI output, so it presents to users as "the dock is broken" rather than "a dependency is missing."dbus-x11. This was verified end-to-end on the dogfood image.Filed on behalf of @tracyjohnsonux by a Coder Agents-generated agent.