Title: Critical Startup Error: Rovo Dev v0.13.46 - "config.yml.lock could not be acquired" (Global Bug) Body: Hello Rovo Dev Team, I am reporting a critical startup failure in the Rovo Dev CLI that appears to be affecting multiple users globally as of February 21, 2026. The Issue: Whenever I attempt to run the CLI, it fails immediately with the following error: Failed to start Rovo Dev CLI: The file lock 'C:\Users\[user]\.rovodev\config.yml.lock' could not be acquired. Technical Details observed: * Version: Rovo Dev v0.13.46 (running on acli v1.3.13-stable). * OS: Windows 11 (PowerShell/CMD). * Symptoms: Even after manually deleting the .lock file, the CLI crashes approximately 10 seconds after startup and recreates the lock, preventing further access. * Logs: My rovodev.log shows an ImportError: DLL load failed related to NumPy during the model initialization phase. This suggests a potential library packaging issue in the latest v0.13.46 build. Steps I have already tried (that did not work): * Manually deleting the config.yml.lock file. * Force-killing all acli.exe and rovodev processes. * Updating to the latest stable ACLI (v1.3.13). * Restarting the system and checking site permissions. This appears to be a regression in the latest update rather than a local configuration error. Is there an ETA for a hotfix (v0.13.47)? Looking forward to a resolution so I can get back to my project!

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Title: Critical Startup Error: Rovo Dev v0.13.46 - "config.yml.lock could not be acquired" (Global B

Vimufast Cowboy

Title:

Critical Startup Error: Rovo Dev v0.13.46 - "config.yml.lock could not be acquired" (Global Bug)

Body:

Hello Rovo Dev Team,

I am reporting a critical startup failure in the Rovo Dev CLI that appears to be affecting multiple users globally as of February 21, 2026.

The Issue: Whenever I attempt to run the CLI, it fails immediately with the following error: Failed to start Rovo Dev CLI: The file lock 'C:\Users\[user]\.rovodev\config.yml.lock' could not be acquired.

Technical Details observed:

Version: Rovo Dev v0.13.46 (running on acli v1.3.13-stable).
OS: Windows 11 (PowerShell/CMD).
Symptoms: Even after manually deleting the .lock file, the CLI crashes approximately 10 seconds after startup and recreates the lock, preventing further access.
Logs: My rovodev.log shows an ImportError: DLL load failed related to NumPy during the model initialization phase. This suggests a potential library packaging issue in the latest v0.13.46 build.

Steps I have already tried (that did not work):

Manually deleting the config.yml.lock file.
Force-killing all acli.exe and rovodev processes.
Updating to the latest stable ACLI (v1.3.13).
Restarting the system and checking site permissions.

This appears to be a regression in the latest update rather than a local configuration error. Is there an ETA for a hotfix (v0.13.47)?

Looking forward to a resolution so I can get back to my project!

Accepted answers

Federico Ciner

Hi there! I'm one of the developers on the Rovo Dev CLI team.

We have identified the source of the issue and are in the process of rolling out a hot fix in version v0.13.47.

We are looking to have this rolled out to all users in the next hour or two, apologies for the inconvenience!

Thanks,

Fed

Jovana Dunisijevic

Hey everyone!

We have a release going out soon to fix this!

Apologies for this!

Please try again in a couple of hours!

All comments

Peppe Iodice

Same issue here as well on Windows 11 and Rovodev v0.13.46.
I tried to observe what happens directly in the folder containing the lock file.

What I’m seeing step-by-step:

As soon as I run acli rovodev run, the existing config.yml.lock file gets deleted.
Immediately after, the CLI recreates a new lock file, but it’s empty (0 bytes).
Roughly ~10 seconds later, the CLI prints the error in console (config.yml.lock could not be acquired) and then the lock file gets deleted again almost right away.
So it looks like the lock lifecycle is unstable: delete → recreate empty lock → error → delete.

What I tried in addition:

I made a copy of the newly generated empty lock file and attempted to set it to Read-only.
With Read-only enabled, Rovo Dev fails with a different startup error on launch:

acli rovodev run
Failed to start Rovo Dev CLI: [Errno 13] Permission denied: 'C:\\Users\\MyUsername\\.rovodev\\config.yml.lock'
✗ Error: failed to execute the command

and regardless it does not fix the original “lock could not be acquired” failure (it still won’t start).

This strongly looks like a regression or packaging/runtime issue rather than local permissions or a stale lock file.

Anyone can drop some hot fix as soon?

mahdido

I have the same issue in windows 11 and also in wsl (debian) from yesterday night i had this problem

Vimufast Cowboy

the developers should work on this issue. its like global bug

Vimufast Cowboy

they even made me to restart my account, deleting files and reinstalling them but it keep bringing the same bug

Grafeeti 282

Workaround I found for the `config.yml.lock` / guard-lock issue (Linux/WSL)

This bypasses the file locking calls that seem to get stuck, by preloading a tiny shared lib that no-ops flock() and fcntl(F_SETLK/F_SETLKW). Not ideal, but it got me unblocked.

1) Clear any stuck processes + remove the global guard lock
pkill -f "rovodev|acli" || true
rm -f /tmp/rovodev_global.lock

2) Build the preload library
cat > /tmp/nolock.c <<'C'
#define _GNU_SOURCE
#include <dlfcn.h>
#include <stdarg.h>
#include <sys/file.h>
#include <fcntl.h>
#include <stddef.h> // for NULL

int flock(int fd, int operation) { (void)fd; (void)operation; return 0; }

int fcntl(int fd, int cmd, ...) {
static int (*real_fcntl)(int,int,...) = NULL;
if (!real_fcntl) real_fcntl = dlsym(RTLD_NEXT, "fcntl");

va_list ap; va_start(ap, cmd);
void *arg = va_arg(ap, void*);
va_end(ap);

if (cmd == F_SETLK || cmd == F_SETLKW) return 0;
return real_fcntl(fd, cmd, arg);
}
C

gcc -shared -fPIC -o /tmp/nolock.so /tmp/nolock.c -ldl
ls -la /tmp/nolock.so

If `ls -la` shows the file exists, LD_PRELOAD should work.

3) Run Rovo Dev with the preload (test run)
LD_PRELOAD=/tmp/nolock.so acli rovodev run

Notes:
- This is a workaround (it disables locking), so use at your own risk.
- Sharing in case it helps others while Atlassian investigates the root cause.

Vimufast Cowboy

i just found out that it only functional on linus inly. thanks for sharing

Federico Ciner

Hi there! I'm one of the developers on the Rovo Dev CLI team.

We have identified the source of the issue and are in the process of rolling out a hot fix in version v0.13.47.

We are looking to have this rolled out to all users in the next hour or two, apologies for the inconvenience!

Thanks,

Fed

Jovana Dunisijevic

Hey everyone!

We have a release going out soon to fix this!

Apologies for this!

Please try again in a couple of hours!

Anon Null

Updated to : v0.13.47

Welcome to Rovo Dev, Atlassian's AI coding agent.

Here are some quick tips:

• Ask Rovo Dev anything in your own words - from "explain this repository" to "add dark mode to this app".
• Use /help for more information and /exit to quit.

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Claude Sonnet 4.6 is now available in Rovo Dev! 🚀

Sonnet 4.6 is now available for all users - try it out today by running /models
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Working in C:\

✔ Using model: auto
✔ Started 3 MCP servers

Working !

Phaskani Msimuko

Thank you very much. The update has Fixed this

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

rovo-atlassian-intelligence