Rovodev upgrade error

[dbonvill]

$ acli rovodev run
Downloading new Rovo Dev version...
✗ Error: no permission to modify files, set '$ACLI_CONFIG_DIR' environment variable to a writable directory or check file permissions: rename .local\share\acli\1.3.21-stable\plugin\rovodev-temp-baa1be32 .local\share\acli\1.3.21-stable\plugin\rovodev: Access denied.

All the rights are corrects, the rename fails because .local\share\acli\1.3.21-stable\plugin\rovodev already exists and is a folder. Anyone else with this problem?

[Alexander Nilsson · Accepted solution]

Hi there,

your read on this is correct, and it is a Windows-specific quirk in how the auto-upgrade swaps the plugin folder rather than an actual permission problem.

On Windows the upgrader downloads the new build into rovodev-temp-... and then renames that folder onto the existing rovodev folder. Windows refuses to let a rename replace a directory that is already there or that something still has open, so it surfaces as "Access denied" even when your NTFS permissions are completely fine. The trigger is almost always a handle still held on that folder: a terminal or editor session that is still running acli, or an antivirus or OneDrive or backup agent touching the directory while the swap happens.

What clears it in practice:

1. Close every terminal and editor that has run acli or rovodev, then check Task Manager for a stray acli.exe or rovodev process and end it.
2. Delete both the leftover rovodev-temp-... folder and the existing rovodev folder under .local\share\acli\1.3.21-stable\plugin\. Removing the plugin folder is safe here, since the upgrade is trying to recreate it anyway.
3. Run acli rovodev run again so it downloads the plugin into a clean folder.

If your user profile lives under a OneDrive-synced path, pause sync before you retry, because OneDrive is a common cause of handles that block the rename. For a more permanent workaround you can point ACLI at a local, non-synced writable directory using the ACLI_CONFIG_DIR environment variable that the error itself suggests.

This exact upgrade failure is not something the public docs cover, so if it comes back even with a clean plugin folder it is worth reporting. You can file it straight from the CLI with /feedback, or open a support ticket here:

https://support.atlassian.com/contact/#/

Greetings,

Alex

[Dr Valeri Colon _Connect Centric_]

@dbonvill welcome to the community. Alexander’s cleanup approach makes sense here. Atlassian confirms Rovo Dev can update independently of ACLI, so the failure is occurring during that plugin update rather than normal Rovo authentication. Since the existing rovodev directory appears to be blocking the replacement, removing the stale plugin directory and retrying is a reasonable workaround. I’d report it if it recurs, though—I haven’t found Atlassian documentation confirming this specific Windows upgrade behavior.

[dbonvill]

Checked there was no running process acli or rovodev.
Cleaned the temp folder (rovodev + 4 or 5 rovodev-temp).
Same error.

Maybe a problem with Windows Defender still holding a lock on the folder at that time.

[dbonvill]

Checked with Sysinternals handle.exe: no process has the folder rovodev opened at that time.