Skip to content

File sync fails when coder_agent.dir is set to a non-home directory #238

Closed

Description

@zedkipp

Current Behavior

File sync fails to install the Mutagen agent on workspaces where the coder_agent resource has a dir property set to a directory other than $HOME.

The error:

Image

I can see the agent was scp'd to $HOME/coder (repo location):

coder@upload-code-pastebin-dcbe:~$ grep -r mutagen-agent /home/coder/*
grep: /home/coder/coder/.mutagen-agentc8a65917-9e3a-40b6-9af9-947bfd9e27ac: binary file matches

Root Cause Investigation

This seems to be caused by an interaction between Coder Desktop's bundled Mutagen binary and the breaking change in coder/coder#21194, which made SFTP/SCP respect coder_agent.dir.

Prior to that PR, SCP landed files in $HOME while SSH sessions used dir. Mutagen's agent installation relied on SCP landing the binary in $HOME and then SSH executing it from $HOME. The original mismatch between SCP and SSH working directories was tracked in coder/coder#16568.

After the PR, both SCP and SSH now use dir. However, Mutagen appears to use an absolute $HOME-based path (/home/coder/.mutagen-agent<UUID>) when SCPing the binary, bypassing the dir setting. The SSH execution step then looks for the binary relative to dir (/home/coder/coder/), and the file isn't there.

SSHing into the workspace and running ls -la ~/.mutagen-agent* shows no files, confirming the binary never lands in $HOME.

Steps to Reproduce

  1. Use a Coder deployment running v2.30+ (which includes the SFTP/SCP dir change from PR #21194)
  2. Use a template that sets dir on coder_agent to a non-home directory, e.g.:
   resource "coder_agent" "dev" {
     arch = "amd64"
     os   = "linux"
     dir  = "/home/coder/coder"
   }

  (The dogfood "Write Coder on Coder" template does this)

  1. Open Coder Desktop -> File Sync
  2. Configure a sync session to the workspace
  3. Observe the error on "Installing agent..."

Expected Behavior

Mutagen installs its agent and file sync begins successfully, regardless of the coder_agent.dir setting.

Workaround

Unsetting coder_agent.dir fully works around this issue.

Environment

  • Coder Desktop: v0.8.0 (macOS)
  • Coder deployment: v2.30.1+ (dogfood, running main)
  • Template: dogfood "Write Coder on Coder"
     (dir = local.repo_dir -> /home/coder/coder)
  • Workspace: Linux (amd64)

Additional Context

Activity

  1. added theissue type on Feb 12, 2026
  2. mrabbani commented on Mar 15, 2026

    @mrabbani

    I am facing the same issue. Is there any update?

  3. ofigma commented on Mar 30, 2026

    @ofigma

    This is blocking a workflow I have in mind. Will this be fixed soon?

  4. RoyGeorgeAda commented on Apr 17, 2026

    @RoyGeorgeAda

    Any ETA on how soon this will be fixed? Quite annoying at this point in time during testing sessions where I need to transfer lot of files and need to scp them individually.

  5. matifali commented on May 14, 2026

    @matifali
    Member

    As of Terraform Provider 2.17.0, a warning is now shown when coder_agent.dir is set to a value other than ~ or $HOME. This does not fix the underlying issue, but it should help prevent users from running into it.

    The longer-term plan is to deprecate and remove coder_agent.dir, along with vscode and vscode-insiders in coder_agent.display_apps, since they depend on coder_agent.dir to open in the target path. For IDEs, the recommended approach is to use the modules from registry.coder.com, or define an explicit coder_app and use the IDE URL handler to open a folder.

    Created a followup issue for deprecation: coder/terraform-provider-coder#509

  6. coder commented on Oct 9, 2026

    @coder
    Contributor

    Update: the underlying issue is now fixed. Coder Desktop bundles Mutagen v0.18.5, which installs its agent using an absolute path (coder/mutagen#10), so file sync works when coder_agent.dir or a dev container workspaceFolder is not $HOME.

    Update to:

    The dir deprecation and plan-time warning were also reverted in coder/terraform-provider-coder#549 and will ship in the next provider release.

    Posted on behalf of @matifali

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

bugSomething isn't working

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions