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]

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