I have prepared PR for the changes required on the aider side. Happy to start the discussion about the possible improvements.

Companion should introduce communication between aider and IDE, so there are additional open feature possibilities of using it in the future (e.g. adding a selected code to the aiders chat, invoking Refactor command on selected code...)

This is an interesting and cool idea. I like it. It's a different spin on something I also just suggested to improve the workflow and adding files to the chat: #2068

There is a VSCode extension that already does this without a rest API. This could be a good way for Jetbrains IDEs and others, but it's generally not the best case solution

@sengokudaikon
Thanks, I checked the extension. It is running aider inside the IDE, which makes it possible to manage /add, /drop automatically. For Idea there also is a similar plugin that integrates aider directly into the IDE. I actually find it better to have it separated from IDE, so that's why I have chosen this approach. Currently IDE extension provides Rest API which aider should be able to use, but I am starting to lean towards the idea of having aider have it's own Rest API for the commands it provides and the external application integrating with aider would be able to use that. The only problem I can I usually have multiple instances of aider running for different projects at once and that would make it harder to manage connections as you would need multiple ports (or having API server running on top of aider instances).

I am interested in Paul's take on this and see what he thinks would be the best approach given his general overview and idea of aider's capabilities.

I would also very much prefer to have aider provide REST endpoints for its commands. This would open up a few use cases and ideally extend its scriptability without the need to fork it or run it from python.

I would also very much prefer to have aider provide REST endpoints for its commands. This would open up a few use cases and ideally extend its scriptability without the need to fork it or run it from python.

+1 to this. The biggest issue using Aider vs. an in IDE solution like Cursor is the inability to "apply" individual proposed edits while looking at the file itself. Sometimes models end up rewriting too much of a file, or tweaking them unncessarily.

Out of interest, is there a use case whereby the IDE's extension can't just use Aider's scripting?

@marvijo-code

Out of interest, is there a use case whereby the IDE's extension can't just use Aider's scripting?

I'm writing a plugin that does exactly that. Compared to having an aider instance that runs as a sidecar and can be used on demand, there are a few downsides of calling aider with the message argument:

1. startup of aider may take 3 to 10 seconds (especially if repo map updates are needed), so the interaction feels slow and unresponsive.
2. aiders chat history can't be used easily and every command will be somewhat transactional. This is uncommon for an AI Coding IDE plugin and users are used to having chat interfaces Pugin workflow p-wegner/coding-aider#47 (popular solutions like cursor, cline, windsurf, ... all provide chat-like ux)
3. As a result of 2. the lack of chat history prevents effective use of caching, e.g. https://api-docs.deepseek.com/news/news0802 which could significantly reduce latency and API costs (although this also depends on the provider and how aider tries to use caching features).
4. You basically have to call aider with the --yes option, otherwise it won't be able to create new files. You will also want to turn off suggest shell commands, because of this. Fine grained user confirmations for individual steps ("Do you want me to run npm install for you?) like e.g. cline has them within a chat interface aren't possible with the provided API of aiders scripting mode.

Especially 1. 2. and 4. significantly affect the ux an aider IDE integration can provide.

@p-wegner Now I understand your use case a bit more, after also thoroughly looking at the PR. This is how I understand how you envision this:

1. open IDE
2. select file(s) probably via Copilot-style "@foo.py @bar.py" or drag and drop
3. IDE extension hosts server which serves these files
4. Whenever you send a command from Aider, Aider retrieves the file list from the server and adds the files to chat

An MCP server would fit this use-case perfectly. Both Aider and the extension can communicate via the MCP server. Workflow changes:

3. Extension communicates with the standardized MCP server instead of hosting a custom one
4. Aider calls the MCP Server to retrieve the files, instead of the custom server

Thoughts: this seems to be limited to just the convenience of adding files to chat. I believe this would only be a start and visual diffs and other features would be added to the extension via the MCP server (we'd probably need some hooks to retrieve diffs before Aider commits)

Would this fit the requirement?

For reference, MCP Server progress is tracked here: #2525

In case anyone interested I have created desktop app built on top of Aider that can keep track of opened files in your IDE and automatically add/drop them from Aider's context (plus much more) -> AiderDesk.

I am thinking about closing this issue as there has not been a word from Paul, if anything like the original idea of the issue is even considered.