Problem
usershell.ResolveWorkingDir (introduced in coder/coder#26102) uses a configured working directory when it exists as a directory, and otherwise silently falls back to the user's home directory. The callers (the agentssh SSH command and SFTP paths, and agentproc) do not distinguish "used the configured directory" from "fell back to home," so a rejected configured directory produces no log or metric.
Scenario: an admin sets the agent directory to a path that does not exist or is not accessible (bad mount, wrong permissions). SSH and SFTP sessions silently land in $HOME. Nothing correlates the rejected directory with the session, so support cannot explain why sessions start in the wrong place.
This is pre-existing behavior. All three resolvers fell back silently before the unification, which preserved the contract rather than introducing it.
How to verify
Read usershell.ResolveWorkingDir and the two call sites (agentssh.Server.resolveWorkingDir and agentproc.manager.resolveWorkingDir). When the configured directory is non-empty but fails the stat/IsDir check, the function returns the home directory with a nil error and nothing is logged.
Desired outcome
When a non-empty configured working directory is rejected and resolution falls back to home, the agent emits a diagnostic (a warn-level log with the configured and resolved paths) at the call sites that have a logger. The shared resolver stays logger-free.
Constraints
- Keep the shared
usershell.ResolveWorkingDir free of a logger dependency. The diagnostic belongs at the call sites.
- The SSH command path resolves against a per-session EnvInfoer (container override), so the log there should reflect the actual resolved directory rather than assume the host.
Follow-up to coder/coder#26102 (deep-review CRF-1).
🤖 Filed by Coder Agents on behalf of @mafredri.
Problem
usershell.ResolveWorkingDir(introduced in coder/coder#26102) uses a configured working directory when it exists as a directory, and otherwise silently falls back to the user's home directory. The callers (theagentsshSSH command and SFTP paths, andagentproc) do not distinguish "used the configured directory" from "fell back to home," so a rejected configured directory produces no log or metric.Scenario: an admin sets the agent directory to a path that does not exist or is not accessible (bad mount, wrong permissions). SSH and SFTP sessions silently land in
$HOME. Nothing correlates the rejected directory with the session, so support cannot explain why sessions start in the wrong place.This is pre-existing behavior. All three resolvers fell back silently before the unification, which preserved the contract rather than introducing it.
How to verify
Read
usershell.ResolveWorkingDirand the two call sites (agentssh.Server.resolveWorkingDirandagentproc.manager.resolveWorkingDir). When the configured directory is non-empty but fails the stat/IsDircheck, the function returns the home directory with a nil error and nothing is logged.Desired outcome
When a non-empty configured working directory is rejected and resolution falls back to home, the agent emits a diagnostic (a warn-level log with the configured and resolved paths) at the call sites that have a logger. The shared resolver stays logger-free.
Constraints
usershell.ResolveWorkingDirfree of a logger dependency. The diagnostic belongs at the call sites.Follow-up to coder/coder#26102 (deep-review CRF-1).