The last piece of the multi-session picker (#50/#51/#52/#53). Without it the original goal — watch the console user's session when they log in — does not work on a normal install.
The gap. Curation treats the registry as the sole source of offerable sessions (#52), and registration is driven by dreamconnect-register@<uid>.service, which waits for /run/user/<uid>/dreamconnect-display.env. Only the headless machinery writes that file, and only the configured account gets a capture daemon. So on a backstage box an attended console session has no daemon, no published display and no register instance — and because it is undescribed while a registry exists, curation drops it from the picker entirely.
It currently appears on the test box only because the display env was hand-written and the register script run by hand.
Owner decision (2026-08-18): attended capture is wired by DEFAULT, with no per-session consent prompt. DreamConnect is an IT-managed remote-support agent, and authorisation is organisational — granted by whoever administers the fleet — exactly as ScreenConnect, TeamViewer and comparable RMM agents behave on Windows. The operator does not ask the console user for permission at connect time. This is deliberate and belongs in the spec, not just in code.
Shape, reusing machinery that already exists and is tested:
- a user unit in the human's account,
WantedBy=graphical-session.target, that publishes DISPLAY/XAUTHORITY to /run/user/<uid>/dreamconnect-display.env when they log in (the backstage env publisher already does this job for headless sessions — check whether it works unchanged for an attended one);
- that account's capture daemon, i.e. the existing classic-mode unit with
--monitor <connector> and --display/--label, so it captures the physical screen;
dreamconnect-register@<uid> enabled system-side. It already waits for the display env and already dies with the session via BindsTo=user@%i.service, so nothing new is needed there.
So a backstage install also wires the detected desktop user for attended capture. shm and socket are uid-scoped, so the two sessions coexist; the drop-in keeps aiming ScreenConnect at backstage as the fallback; the registry lists both; curation offers both.
Acceptance: on a box with a backstage install, a human logging in at the console appears in the operator's picker by name, selecting it shows their real screen and routes input there, and logging out removes the entry. No hand-written files.
The last piece of the multi-session picker (#50/#51/#52/#53). Without it the original goal — watch the console user's session when they log in — does not work on a normal install.
The gap. Curation treats the registry as the sole source of offerable sessions (#52), and registration is driven by
dreamconnect-register@<uid>.service, which waits for/run/user/<uid>/dreamconnect-display.env. Only the headless machinery writes that file, and only the configured account gets a capture daemon. So on a backstage box an attended console session has no daemon, no published display and no register instance — and because it is undescribed while a registry exists, curation drops it from the picker entirely.It currently appears on the test box only because the display env was hand-written and the register script run by hand.
Owner decision (2026-08-18): attended capture is wired by DEFAULT, with no per-session consent prompt. DreamConnect is an IT-managed remote-support agent, and authorisation is organisational — granted by whoever administers the fleet — exactly as ScreenConnect, TeamViewer and comparable RMM agents behave on Windows. The operator does not ask the console user for permission at connect time. This is deliberate and belongs in the spec, not just in code.
Shape, reusing machinery that already exists and is tested:
WantedBy=graphical-session.target, that publishesDISPLAY/XAUTHORITYto/run/user/<uid>/dreamconnect-display.envwhen they log in (the backstage env publisher already does this job for headless sessions — check whether it works unchanged for an attended one);--monitor <connector>and--display/--label, so it captures the physical screen;dreamconnect-register@<uid>enabled system-side. It already waits for the display env and already dies with the session viaBindsTo=user@%i.service, so nothing new is needed there.So a backstage install also wires the detected desktop user for attended capture. shm and socket are uid-scoped, so the two sessions coexist; the drop-in keeps aiming ScreenConnect at backstage as the fallback; the registry lists both; curation offers both.
Acceptance: on a box with a backstage install, a human logging in at the console appears in the operator's picker by name, selecting it shows their real screen and routes input there, and logging out removes the entry. No hand-written files.