fix(agent): start the session process only for remote sessions - #1995
Conversation
Let maintainers know that an action is required on their side
|
fb3dd0d to
d52dfe1
Compare
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
🟢 Approval recommended
The remote-session gate is correctly integrated and covered by focused tests.
Pull request overview
Restricts the session host to remote Windows sessions and improves DVC diagnostics.
Changes:
- Gates session-process startup by session kind.
- Adds focused readiness tests.
- Logs session IDs and actionable DVC failure hints.
No material issues were identified.
File summaries
| File | Description |
|---|---|
devolutions-session/src/main.rs |
Logs the supplied session ID at startup. |
devolutions-session/src/dvc/io.rs |
Adds contextual hints for known DVC errors. |
devolutions-agent/src/session_manager.rs |
Prevents console-session startup and adds tests. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Balanced
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
d52dfe1 to
de5710b
Compare
Devolutions Agent starts a session host process inside user sessions to serve the Devolutions Agent virtual channel. Only a remote session can serve that channel, because it needs an RDP client on the other end to open it against. The agent recorded whether each session was a console or a remote session, and the code stated in a comment that the process is only started for remote ones.
It was never actually restricted that way. The decision to start the process considered only whether the session was ready - registered, and past the logon or unlock event it was waiting for - and never consulted the console-or-remote value it had recorded. Console sessions are registered when they connect and Windows reports a logon for them like any other session, so they satisfied every condition the check applied. Signing in at a machine's console therefore started a session host process there, which found no RDP client to open the channel against, failed immediately, and exited. It repeated on every local sign-in.
The session kind is now part of the decision, so the behaviour matches what was intended: console sessions are still tracked, so that a later upgrade to a remote session is picked up, but the process is only ever started for a remote session.
This also removes a class of misleading support logs. The session host writes its log per user rather than per session, so these console-session failures were indistinguishable from a genuine RDP connection failing to establish the
channel. To make the remaining failures readable, the session host now records the session it was started in.