Rovo Dev CLI improvement proposals

[Jan Lipponen]

Hi,

I have some improvement proposals for the Rovo Dev CLI to make it more usable and predictable.

1. Make `--config-file` and config files unambiguous

Currently, the `--config-file` flag behaves ambiguously. It seems to mix three different functions:

• Using a local config file at the given path
• Creating or modifying a config file at the path
• Appending a global config with the file at the path

Meanwhile, the help text simply says "Config file", and the Manage Rovo Dev CLI settings section places it under "Use a new configuration file".

As a seasoned command-line tool user, I expect `--config-file` to mean: use the configuration file at the given path.

• No automatic edits to it
• No implicit merging with global configuration
• The only reasonable automation would be creating a new empty config file if none exists at the path

This would allow users to define explicit and unambiguous permissions, which I believe is increasingly important. As it stands, I feel I don’t have full control over what the tool can and cannot do. For many teams, this makes the tool unfeasible to use due to security concerns.

2. Allow permissions lists as command line arguments

Currently, the tool only offers an all-or-nothing approach via the `--yolo` flag. This is clearly insufficient.

I propose replacing `--yolo` with something like `--permissions []` If necessary, "yolo" could remain as one of the options in the list, though I would advise against it.

Using `--permissions` should override both global and local configuration permissions.

Also, the help text for `--permissions` should list all available permissions.

This would allow users to run the tool with explicit permissions without needing a config file, which is useful in many scenarios - especially during development.

3. Make Rovo Dev CLI aware of and respect the given configuration

Currently, I'm trying to run the tool with a prompt:
```

acli rovodev run --config-file .rovodev/config.yml "Do <stuff>. Only use commands and tools you have permission for.

``` 

Yet immediately, the tool tries to use a tool not listed in the configuration file and asked for permission to use it. I even removed the global configuration file before running the command, but the behavior persisted.

The tool must respect the given configuration and reason through its tasks using only the tools and permissions provided. Otherwise, it’s impossible to build repeatable workflows with known tools and permissions.

4. Create a Bitbucket pipelines pipe for Rovo Dev CLI usage

This would make using the CLI in pipeline contexts more convenient.

---

Trouble described in point 3 was the final straw for me while trying to use Rovo Dev CLI in a Bitbucket Pipeline. It’s unfortunate, because the tool has great potential to improve our workflows. In this specific case, I wanted the tool to report and maintain potential Python vulnerabilities (found with `pip-audit`) to a Confluence page. This is wanted because the same scan happens in +10 pipelines.

I hope this feedback reaches the Rovo Dev CLI developers!

Best regards,

Jan

[Nikola Perisic · Accepted solution]

Hello @Jan Lipponen 

Those suggestions are great, I would suggest to use one of the discussion groups instead. It suits better, this is the space for questions.

[Jan Lipponen]

Thanks Nikola!

I did try to follow the link Rovo Dev CLI provides for leaving feedback, but it seems I clicked the top navigation "Ask a question" when I should have pressed the `Write an article` 😥

Reposted in the better suiting group:

https://community.atlassian.com/forums/Rovo-for-Software-Teams-Beta/Rovo-Dev-CLI-improvement-proposals/td-p/3138489

Thanks for the advice! I'll accept your answer 👍 This now redundant post can be deleted, if moderation so wants.