IDEs, Agents and Development Tools

Overview

You can use any IDE, coding agent or development tool with AI Workbench.

Edit local projects with any tool on your laptop. Remote projects require connecting to the location, typically through SSH.

VS Code and its forks attach directly to the project container, local or remote.

VS Code, Cursor and Windsurf all support connecting to a running container. The difference is the extent to which you need extensions vs the extensions being built in.

Coding agents like Claude run inside the project container through the CLI.

The container provides sandboxing and GPU access. Settings, permissions and hooks in the repository control what the agent can do.

Web-based IDEs should be installed in the project container.

Install tools like JupyterLab and Marimo directly in the container. Manage them as web applications from the Project Tab.

Key Concepts

Dev container

A container being used for interactive development. Typically implies an IDE or agent attaching to it. Used interchangeably with project container.

Remote connection

Configuring an IDE or agent to access a remote machine through SSH. Allows you to work on remote files using a locally running tool.

VS Code and Forks

VS Code and its forks are all the same for AI Workbench.

The configuration patterns are same in VS Code, Cursor and Windsurf. The difference is the extent to which you need extensions vs the extensions being built in.

For example, Windsurf has SSH and dev container extensions built.

You do not need to use the devcontainer.json file with AI Workbench.

VS Code forks have a simple feature that let you connect them to a running container. This avoids the requirement of a devcontainer.json.

You can add the relevant server and extensions to the container build.

For various reasons, AI Workbench removes the project container when you stop it. Anything installed into the read/write layer will be gone the next time it starts.

You can avoid this by installing the server and extensions in a build script. This keeps everything visible, versioned and editable.

Web IDEs

JupyterLab is often preinstalled in the project container.

If that’s the case, then you can configure the project to run it as a web application by adding it. After that you can start it from the project tab and get to work.

You can use any Python notebook web app that you can install in a container.

It’s the same as installing and configuring JupyterLab. Dependencies go in the container and you configure the applicaton management in the Desktop App.

After that, you manage the web IDE from the project tab.

You should install plugins or extensions during the container build.

This is similar to the situation for the IDE server and extension for VS Code forks.

You can install them at runtime, i.e. include the instructions in the app configuration but this will lead to longer start times.