From Hiep: Previously, I had a discussion with Robert and Tim regarding the display of the Code tab. We agreed that, when connecting to local backends, the Code tab should not be displayed, as users may prefer to use their own IDEs instead.

For cloud environments, displaying VSCode seems like a reasonable approach.

Are we sure we want to do this? I really don’t like the fact that you cannot modify local files just from the UI (especially the file is sandboxed & put into some random git worktree) -- especially when you want to throw a few files into the workspace / run some commands to see what's going on there. If we are worried about this, I think it is especially true since we are actually launching a Dockerized agent server as backend. I think the better flow would be: 1. Dockerized Agent Server: If the user is launching a Dockerized agent server, VS Code should already be a dependency inside that Docker image. In that case, I think we should just support the Code tab. 2. Local Agent Server: With respect to the local agent server, we should be smart and show the user that the agent server is not installed. We can include a prompt to tell the user how to fix this; they can just send this prompt to the agent to get it resolved, or showing that this tab is disabled and they can use their local IDE. More detailed description here: https://github.com/OpenHands/agent-canvas/issues/401 If we are worried that this could create confusion for the user. We could just hide it under the three "dots", but I don’t really like the fact that we support VS Code but we just remove it.

Yeah i don't know why VSCode was removed. Would be good to have it added back if we can.

Could we launch the actual vscode with

code

/ forks command?

@calm-artist-7206 my initial thought was that when VS Code is not available, we should just display a helpful message in that tab and then include the prompt where a user can just copy and throw it to their local agent to set things up

If this works without any performance hits I think this is amazing. On the topic of showing when not supported I like this idea:

Alternatively, add a capability/feature-detection endpoint on the agent server that reports which services are available (VS Code, terminal, browser, etc.).

There is a lot of back and forth requests happening already and I'm weary of adding another one that impacts UI visibility. So a static supported array from the server at launch sounds like a good call. Either the code editor with vscode shows because your backend supports it or it doesn't.

Alternatively, add a capability/feature-detection endpoint on the agent server that reports which services are available (VS Code, terminal, browser, etc.).

I think we already have this supported in agent-server irrc, if it is not yet supported, it is not hard to get it in (one prompt away). With respect to sending prompts, I think sending the prompt to the agent depends on the assumption that the agent has access to their local machine, which i proposed here: https://openhands-ai.slack.com/archives/C06QT0AGY4W/p1778686194092719

What would that prompt look like to get an agent to set it up? Would it work just that one time or for every time you run the agent canvas going forward?

You just send it ONCE and agent configured the vscode dependency locally so local agent-server can access it. In the future, everytime reload canvas, you can reuse that

Just to clarify, my thinking is this: if the agent is local, it has access to the local machine, it can do... so much. My little one uses AppleScript for fun, schedules stuff, uses its Chrome to nag me on Slack, starts and restarts and sends stuff to VSCode, uses whisper, runs whatever things. I... am thinking that maybe it could be worth to try to let the agent figure out some things on local machine... rather than code them in. But maybe I'm missing something!

https://openhands-ai.slack.com/archives/C06QT0AGY4W/p1778686194092719 looks like you are probably in-favor of this issue 😄

SGTM - and, aha! docker needs some setup 🤔

yeah, and each environment is different, so that's why i think we can always have an unsandboxed local agent-server available that can help user sort these type of setup stuff out

That makes total sense to me! Your personal AI engineer 🙏 You know, so it happens. I dug down this screenshot from June 2024 (!). Do you remember we used to tell OpenDevin that it's an AI engineer? 🫠

I was thinking about that earlier too...my setup right now is 3-4 agent-canvas instances running with docker containers for my different local workspaces. Its fragile and takes manual starting, and configuration for one parent agent-canvas to then see an switch between all those backends. So if I had a way to run a single instance that could spin them up that would be pretty great. But how much power does it give the non sandboxed agent to run wild on my system 😱

my setup right now is 3-4 agent-canvas instances running with docker containers for my different local workspaces.

This is something I really want to do too. Basically, we want to have a consistent way of setting up child-agent-canvas so that we can just have one master agent canvas that uses the local agents themselves to help you configure different agent server backends on different machines. The agent could just SSH on your behalf and install stuff there. If you actually turn on the confirmation mode, the agent will ask you to confirm risky actions, so in that case, it is kind of okay to have non-sandboxed agent runs wild on your system. More details here: https://github.com/OpenHands/agent-canvas/issues/233

It can also be approached from the startup scripts too https://github.com/OpenHands/agent-canvas/issues/226 . If I can easily chain my run commands with the specific ports, files, api keys I need it makes for a very powerful and flexible setup

yes agree! i think 226 is a pre-req for my proposal here