I want to raise an important issue I encountered while using the Rovodev CLI from Atlassian.
Despite my repeated efforts to restrict its scope, the CLI continued to gather data from my entire local machine, not just the project directory I was working in. It persistently searched outside my working folder — even diving into sensitive directories like those named “products” — indexing every file name it could access. Re-issuing instructions to adhere to the task at hand, rovodev continued to index folders throughout my system (after being given explicit instructions to stay in the projects working directory).
Even more concerning:
The CLI explicitly admitted that information about these indexed files had been sent (indirectly) to Atlassian systems. That means even folders completely unrelated to my project were scanned and reported — something I never consented to.
This is a serious breach of developer trust. Tools like this should never index or transmit data from outside of the defined project scope — especially not without clear consent or explicit user configuration.
If you're using Rovodev CLI, I strongly recommend:
Running it in an isolated, sandboxed environment.
Monitoring its network activity.
Keeping an eye on what directories it's accessing.
Atlassian needs to clarify and rectify this behavior immediately. Transparency and user control are non-negotiable in developer tooling.
—
Stay secure. Stay aware.
Despite the above - and i do not need to say this, the CLI is by far one of the best i have used. I will continue to use this CLI, but will monitor the activity.
Hi Patrick,
Thank you for reporting Rovo Dev CLI's behavior to us, and my previous reply on how we handle data and privacy terms stands. We will investigate more into this case and implement mitigations based on the findings, and we apologize if Rovo Dev CLI didn't work as expected.
In the meantime, if you are concerned about Rovo Dev CLI working outside of immediate directory, you can:
Claude has sometimes been caught trying to "narc" out users for various things.Not saying this is the case, but maybe the blame lies with Anthropic's model?
Hi there,
I liken this learning to the early days of cloud adoption by enterprise, inadvertently tolerating TOO many permissions. This happened with FS and telco clients I've worked with previously.
The kneejerk response from enterprise, especially cyber and networks functions, is to lock it down which can slow adoption.
Great advice from @Patrick Matthews to start cautiously by sandboxing, but also from @Peter Wu to review config.yml and .gitignore. In enterprise, I could anticipate different privilege levels for the use of Rovo Dev CLI, not dissimilar to other software.
@jeff kazzee's point also highlights that enterprises may end up not liking the foundational model default choice in future (?).
A lively discussion, but really helpful as everyone refines their approach.
Thanks,
Justin