Hello! Looking to get some feedback on a runtime configuration prototype for developers who add a repo for the first time. Pain point: Getting a runtime setup with the necessary dependencies can be time consuming. Additionally, once setup, developers want an easy way to use that environment in future OpenHands conversations. [Related roadmap item] We are considering a flow that lets you configure your runtime, and then save that configuration for later reuse. Today, OpenHands runtimes are all the same and need additional configuration (usually through a setup.sh) to work for certain repos. Here's a rough UI prototype: https://openhands-ui-prototypes.vercel.app/ Curious to get feedback on: • Ideal way to configure a runtime - would you like to bring a custom image, or would you like to have prebuilt installers for popular tools/languages? • Snapshotting runtime environments - would you like to snapshot a point-in-time runtime config so you can be resumed it later? • Does a GUI wizard ever make sense here, or do you prefer to configure it as code (in something like an

environment.json + setup.sh

, etc.) • What other challenges do you have with setting up a repo for the first time on OpenHands?

I built my own image for this pain point (local hosted OH, local inference) However, wouldn't a devcontainer setup work wonders here? Perhaps OpenHands could be a https://containers.dev/features folks could add to make everything "just work" When you open a project for the first time in the web version of OH vscode tab, you could hit the "Reopen in container" pop-up and have everything there. Very useful for teams working on the same codebase needing reproducible dev environments

Good tip Paul! I personally need to look into Devcontainers a bit more, but does seem like it could be a good option

I'm vibe-testing codex (the software), and I just noticed this on codex cloud version. It seems... idk, potentially handy 🤔

Yes, definitely! I think it's a useful feature and directionally where we want to go. I think Codex dropped startup times from 48s to 5s as a result. Here's a snippet from their docs:

Environments that are cached will have the repository cloned with the default branch checked out. Then the setup script is run, and the resulting container state is cached for up to 12 hours. When a container is resumed from the cache, we check out the branch specified for the task, and then run the maintenance script. The maintenance script is optional, and helpful to update dependencies for cached containers where the setup script was run on an older commit.

We will automatically invalidate the cache and remove any cached containers if there are changes to the setup script, maintenance script, environment variables, or secrets. If there are changes in the repository that would cause backwards incompatibility issues, you can manually invalidate the cache with the “Reset cache” button on the environment page.

On this note, there's that tiny thing: ability to send the prompt before the runtime started. It's incredible how much it matters for usability. Just fire it up and switch tab. No waiting for minutes only to add an Enter thinky spin

Cursor has something interesting where it queues a message if you want to add something to the active thread; same UX could work here: queue first prompt for when env is up and ready