Feature Request: VSCode Extension for Prompt Requests with selected code or files immediately in the context

[4tal]

What problem or use case are you trying to solve?

Interacting with OpenDevin requires copying and pasting file paths or content into the prompt request, which can be time-consuming. This process disrupts the workflow and reduces efficiency.

Describe the UX of the solution you'd like

VSCode extension that allows users to interact with OpenDevin directly within the editor. Users should be able to:

1. Select code snippets directly in draft popup to send to OpenDevin.
2. Right-click on a file and send it as part of a prompt request.

If you find this feature request or enhancement useful, make sure to add a 👍 to the issue

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for over 30 days with no activity.

[Paulmicha]

Looks like https://github.com/morph-labs/rift

[neubig]

In addition to rift that @Paulmicha mentioned above, we can also look at continue: https://www.continue.dev/

[jbragg]

There's also a new YC company building on a fork of continue.dev, called PearAI: https://www.ycombinator.com/companies/pearaia

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[farzbood]

Aider supports VSCode too.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[neubig]

We got a comment from our user survey that this would still be an issue that people want!

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for over 30 days with no activity.

[neubig]

There are a lot of requests for this, so if someone wanted to take a stab at this and sharing it open source we'd love the contribution!

[Paulmicha]

https://github.com/cline/cline might be relevant for discussing implementation and UX.

[qdrddr]

https://github.com/RooVetGit/Roo-Code (based on Cline) can be a good candidate to use as a base to integrate with OpenHands without building its own extention.

[pratulgupta]

https://github.com/voideditor/void is also an option, but it is less attractive because it is already a fork of VSCode. I plan to explore the options mentioned here and share my findings. If you are interested in collaborating, please don't hesitate to reach out.

[pratulgupta]

I reviewed the following offerings to base the OpenHands specific implementation:

1. RooCode - fork of Cline. Seems less discerning about PRs compared to Cline
2. Cline - enterprise focus, open, and thoughtful product management. No IntelliJ support right now, but it is being considered
3. Continue.dev - had issues compiling. Has IntelliJ support as well. It is less popular (stars and forks) than Cline
4. VoidEditor - a fork of VS Code. With VS Code cracking down on the forks and limited upside, making it less desirable

I plan to base my initial efforts on Cline as a fork for OpenHands as seemingly. I hope Cline could become a dependency instead of a fork to reduce maintenance efforts but that will be a different workstream for me.

Could someone in Open Hands product management role give feedback on the approach and the choice? I want to get some validation before spending much time on Cline.

[enyst]

For the record, slack discussion.

I think maybe we can look at this in multiple ways. Here is just one, please take it as just some brainstorming fodder, and feel free to shred to pieces if it seems inaccurate or doesn't fit what you'd like:

The first important question, it seems to me, is whether a vscode extension is an alternative frontend to OpenHands, or not.

I think the answer here should be yes: I imagine a tab where the user can enter a message, the extension communicates via socket.io with the openhands server, sends the task, gets the results, displays them.[1]

Note: OpenHands 100-feet view

• backend -> communicates via socket.io server -> frontend, by default a web UI

Example: Plan/Act

Allow me to take the Plan/Act mode as an example of seemingly more advanced functionality.

OpenHands actually has the backend for that:

• we recently merged a readonly codeact agent, a version of the agent that the user can use to explore the code and - if they want - plan; it has tools to read, not to "act"
• both agents, the default codeact and the readonly one, can have different LLMs set by the user
• so when an agent is running, it will run it with its own LLM.

OpenHands doesn't have a visual interface that makes use of this functionality.

Maybe, if you think plan/act is great UX, we could take this flow and display it in a vscode tab, name it simply and clearly as plan/act modes?

To note, for it to work, we would need the appropriate API routes, to send / receive this information. The current web API server is very tightly coupled to the current web UI frontend, which is limited - it's disconnected from these backend functionalities. So I imagine we would add API endpoints like set/get the plan/act modes options, and set/get current mode.

For the extension, this is just an example of functionality in addition to or on top of the basic vscode tab. I guess such tab would include the chat-like components that are usual for user/agent communication.

---

[1] If there are reasons for the answer to be 'no', then it would seem very important to me to point them out. I do think this question is essential and shapes the rest of the discussion/issues/workflow here.

[pratulgupta]

@enyst. I agree with the 100-feet view you mentioned in which the VS Code extension works with the open hands server/docker container. I believe it is possible or we make it possible. Containerized execution of OH is a strength that should make it very appealing to larger, risk-averse enterprises. I am sure some change will be required to the current APIs, but it will take some digging to figure out the gap to support the target VS Code Extension UX.

Two key questions need to be answered to start:

1. How is OH differentiated from other code agents? The answer will ensure that the technical approach aligns with the strategy
2. What is the VS Code UX we should strive for? This answer will help us decide whether to start the extension development from scratch or fork another extension.

[rbren]

So it sounds like there are a couple separable desires here:

• For this issue, I think we should focus on making VS Code a window into the current OpenHands functionality.
• Second, there is probably new functionality (e.g. plan/act) that we want to have, which might make even more sense once we have an IDE extension

Focusing on #1, some open questions:

• At minimum I think we need a chat window, which will kick off a new OH conversation
  • Does it have to connect to a running OH server? Or does it start up OH on the fly?
  • Does it run commands in a container, or do we use LocalRuntime to use your local machine?
  • Does it edit files locally, or does it clone the repo and pass its changes through a remote branch on eg GitHub?
    • probably local
• Can a VS Code user see OH working inside of VS Code? E.g. can they see the edited files?
  • This seems like must-have
  • We could potentially use SSH mode to connect into the OpenHands runtime container
  • Or if OH is working on local files, that's easy
• Stretch: can we register the local VS Code as a "remote runtime"?
  • it could connect to the websocket, listen for e.g. CmdRunAction, run it in the terminal, then send back a CmdOutputObservation
  • ditto for file ops
  • we're not 100% set up to do this but it wouldn't be super hard, and it's always been a goal of mine

[enyst]

@pratulgupta good questions! I think Robert addressed the second and implicitly the first, allow me to just point out relative to the comparison with e.g. Cline:

• openhands gets the task, goes and explores, edits files, lints, builds and runs tests; fixes the errors; tries again; can commit and make PR; and reports back when the feature is done.

In other words, it seems to me that by default it does, if the user wants it to, a lot more than assist the user with some piece or another piece of this flow.

A common thread in Robert's questions is local vs docker/remote. That's a very interesting question! I think my view on the extension "as a frontend" implies the second, e.g. things are happening elsewhere, we display and handle user interaction. That might be wrong! If we decide on local, it seems that the user experience could benefit fully from vscode terminal integration, git diff view, and others.

[pratulgupta]

Thanks, @rbren, @enyst

If we focus only on the issue as reported, #1 and its approach sound good. However, I would recommend using this issue as a trigger to see what the ultimate UX goals are. These goals could take us beyond the current OH capabilities, but they will help ensure that the decisions support #1 as the first step while working towards some version of #2. Starting from scratch vs. forking another project will also become clear.

Does OH want to stay fully agentic (yolo mode), or also support other code editing capabilities like auto-completion? If it is the former, do we expect developers to use OH in conjunction with other extensions to support their workflow?

Local vs. Docker/Remote is a parallel question to answer. While I do prefer dockerized approach, I don't know enough to compare and contrast. Could some approach like workspace_base for docker be used here to support CI pipelines? Or maybe make the extension is the one executing the CI tasks?

[enyst]

IMHO features like IDE autocompletion are completely different than what openhands is doing, and the IDE is doing it anyway. Idk, why would we? 🤔

I think Robert's #1 approach is fine. My only quibble there, as I tried to describe, perhaps badly, is that "plan/act" is not new functionality for openhands backend. It's already capable of it, or close enough. The way I see it, it replaces a drop-down (readonly agent, codeact agent) as we have in the default web UI, with a toggle, in some other interface (label the first agent "plan", the second "act", if we like these names).

I do take the point that even that, still requires some changes, and maybe that warrants excluding it from the first implementation of an extension. That's fair enough, and totally your choice, @pratulgupta , if you care about it so much that you really want to go forward with it in mind. If not, leave it aside, it will be a bit simpler. It was only an example anyway, since we discussed it on slack.

The more important point, it seems to me, is that we should focus on making openhands functionality available in vscode. Something like autocompletion seems far away to me. 🤷‍♂️ I would suggest we don't need it?

[enyst]

Does OH want to stay fully agentic (yolo mode)

I would point out that YOLO mode, as I've seen in some tools currently, appears to mean by default: agentic mode applied to local files. By contrast, OH by default is agentic applied to docker/remote copies.

OH does have features like prompt confirmation, which we may want to toggle on by default, if we apply it to local files. The agent is still doing what it thinks it should do, but we can stop it to show the command to the user, and let them approve or reject.

The answer to your question is yes, I think, regardless of this safety toggle. (I mean, it seems to me it follows from these discussions that we don't aim to change OH into something else? Into an IDE?)

[pratulgupta]

@enyst, sorry, I should have been clearer with my autocomplete remark. I meant generated code fragments or a coding assistant that will still be needed outside the agentic workflow supported by OH. This is not what an IDE supports directly. It will require some LLM/AI-enabled extension like Cline/Continue. The reason I would want to fork of (or, in the best case, a dependency on) one of these extensions would mean that agentic parts can be served by OH while using rest of the functionality from the base extension.

As such, I don't care about a specific implementation. However, I want the implementation to be valuable to the users and maintainable by this team. I hope we can develop a common point of view on this.

[enyst]

I thought Cline works in its tab, integrated with settings, diff, terminal, but doesn't do autocompletion?

[enyst]

There's nothing to be sorry for, probably it's just me, I don't know in detail most vscode extensions. I think I applied Cline on an almost empty vscode, and it didn't have autocompletion. I enabled github copilot, and that did it. But I may misremember.

[pratulgupta]

(I mean, it seems to me it follows from these discussions that we don't aim to change OH into something else? Into an IDE?)

No, certainly not looking to make it a new IDE, but I want to understand the target state in more detail from a user experience perspective.

Yes, the yolo mode is applied to local files, but generically it is applied to a codebase - which happens to be local. Apart from the location of the codebase, it is similar to OH.

I will record some relevant experiences as examples by tomorrow morning (ET) for us to use in our discussions.

Thanks for the engagement.

[pratulgupta]

@enyst, you are right. Cline does not have an autocomplete feature. It was Continue.dev I had seen it in.

I will explore these two options further to assess how they could work. I will share progress as I make it. Hopefully, it will give the team more time to share thoughts on the target developer experience and give me deeper insights into the extensibility efforts.

[bartlettroscoe]

Would it make sense to consider an integration between this new Openhands vscode extension and the VSCode continue.dev extension?

Gemini 2.5 seems to think that would be a pretty good idea:

https://g.co/gemini/share/e5d22928b086

While I'm really loving the new vscode GitHub copilot agent mode, the prospect of being able to use that toolset with completely locally hosted models in an air-gapped environment seems incredibly unlikely. It seems like an improved continued.dev extension with the vscode GUI and using OpenHands for agentic mode on the backend with tool use could be a pretty good open-source competitor for vscode + GitHub co-pilot agent mode.

So open-source tools like that, paired with increasingly improved open-source models that can be run locally, would give us equivalent features in 6 to 12 months (which is about the amount of time that it's taking the open source llama models to reach the level of proficiency as the frontier closed models).