Rovo CLI not working

Question

I already installed ROVO and created and added the API key with my qualcomm email.

Getting below error on trying to run ROVO CLI:

C:\Users\aredhu>acli rovodev run
2026-08-06 15:56:03.266 | ERROR | rovodev.modules.site_selection:get_sites:56 - Failed to fetch sites from https://api.atlassian.com/rovodev/v3/sites: Failed to connect to the Rovo Dev API on request error,
please try again later.
Run acli rovodev --restore 5d31e1a4-138e-4aaa-bd68-34c40b3930b1 to resume your conversation
╭─────────────────────────────── Error ────────────────────────────────╮
│ │
│ Rovo Dev CLI crashed unexpectedly. │
│ │
│ • Restart with --restore to pick up where you left off. │
│ • Optionally, run acli rovodev log to view the full error trace. │
│ • Optionally, use /feedback to report this issue. │
│ │
╰──────────────────────────────────────────────────────────────────────╯
✗ Error: failed to execute the command

C:\Users\aredhu>

Dr Valeri Colon _Connect Centric_ · Answer

@Akshat Redhu welcome to the community. The top-level “Failed to connect” message isn’t enough to identify the cause. Run acli rovodev log and check the underlying request error. On corporate networks, Atlassian has a known Rovo Dev CLI issue where proxy settings may be ignored, causing API connection failures. If the log shows a timeout/proxy or certificate error, that will narrow it down; otherwise, verify Rovo Dev is activated, your scoped token is valid, and your site has Rovo Dev credits.

Gabriela Perdum · Answer

Hi @Akshat Redhu, that wording rules out your API key. A call that actually reaches Atlassian and gets refused comes back with the suffix "on http status error", which is what an entitlement or permission problem looks like. Yours says "on request error", the other branch, where the request itself didn't complete. So it isn't your key.

The cause is in the log. Run acli rovodev log, or open it yourself (documented default is ~/.rovodev/logs/rovodev.log, so the .rovodev folder under C:\Users\aredhu), and find the lines starting "Request error:" around 15:56:03. That prefix turns up on any failure, so what matters is the bit after it.

On a corporate Windows box I'd expect those to read [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed. The only other public report carrying your exact suffix was Windows 11 behind Zscaler, same sites endpoint, and the certificate line was down in the log: Rovo Dev CLI SSL certificate issues on Windows. The rovodev half does its TLS in Python against a bundled certifi CA list while the rest of acli is Go and goes through the Windows certificate store, so the root your IT pushed into Windows is invisible to this one code path. Worth confirming that split first, since acli jira project list should still work from that same prompt. Someone hitting this same certificate failure still had acli jira dashboard search working.

The workaround is written up on ROVODEV-39. It names REQUESTS_CA_BUNDLE or SSL_CERT_FILE, and for an httpx client SSL_CERT_FILE is the one that gets read. From cmd, same window: set SSL_CERT_FILE=C:\path	o\corporate-ca.pem then acli rovodev run. Your IT team will have that root already; export it Base-64 X.509 out of certmgr.msc if you need to build the PEM yourself. I haven't run this against your build, so treat it as the first thing to try rather than a promise. A proper flag is still open as ROVODEV-25, "Support for Custom CA Certificates in Rovo Dev CLI", Gathering Interest, 18 votes.

A timeout with no certificate text would be ROVODEV-34 instead, where the CLI builds its own httpx transport and doesn't pick up HTTP_PROXY or HTTPS_PROXY.

Your paste stops at the wrapper, so this is me going off the pattern. Post that Request error line, assuming it still does it, and it'll be settled.