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\to\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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.