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):

1. Manually deleting the config.yml.lock file.

2. Force-killing all acli.exe and rovodev processes.

3. Updating to the latest stable ACLI (v1.3.13).

4. 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!

[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

[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

[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!

[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

[mahdido]

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

[Vimufast Cowboy]

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

[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?

[Vimufast Cowboy]

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