doing some research w/ claude now

Screenshot 2026-05-11 at 10.51.47 AM.png

We need some kind of sandboxing mechanism, but I agree we should do better than docker

In another occasion, i could have agent-canvas running on a already sandboxed VM, so doing this is actually ok

I do hope the default path is dockerless, otherwise we are just walking through the OpenHands GUI again lolsob

^and that's true for our CLI too

one main gap i'd like agent-canvas to fill is for it to replace all my CLIs usages.. and by default sandboxing everything, it won't really do that for me

Hermes web UI looks like a serious competitor for agent-canvas, they are sandboxed & you can launch them with one line

docker run

https://github.com/nesquena/hermes-webui/tree/master So how do you feel about: 1. having the

npm run dev

by default run everything locally w/ confirmations & show explicit warnings that people have to acknolwedge before they run automation 2. and a parallel

docker run

command that will run

npm run dev

inside the container so everything is sandboxed, similar to this hermes web ui?

and the claim that you can run "claude code / codex" with agent-canvas typically comes w/ the cost of configuring these in the sandbox, if we by default run everything locally - it would simplify the setup of all these ACP agent as well and provide quicker time to value

hmm or actually, we can let the user select this in the onboarding, what do you feel about this: Select the agent servers you want to launch 1. Locally unsandboxed - can seemlessly connect to your local environment, programs, etc - BUT very risky, especially if you are running automation, use with case 2. Locally sandboxed - requires you to get docker running first, but more secure. And you can select ONE, or BOTH - since we do support flexible amount of backends

nevertheless, even with sandboxing, agents like CC/Codex still requires you to confirm stuff, which i think might be a good initial design we could follow as long as we make the option to: 1. auto-approve 2. sandbox agents very explicit

I think

npm run dev

should be sandboxed though. I'd be open to making it a "confirmation mode" launch but everyone hates confirmation mode

but I'd want it to start docker for me, not make me reinstall

which I don't think is particularly possible without a backend running

we could make `npm run dev`: • check for docker ◦ if installed, prompt for PROJECTS_DIR ◦ if not installed, prompt for DANGEROUSLY_DOCKERLESS

we could probably do something funky, where the script doesn't exit right away, it just says "go to localhost:8000 to complete your setup"

and maybe it's....running a tiny backend? not sure how the frontend would call back out to setup script to start a backend

Summary The user asked me to summarize a Slack discussion thread about an OSX desktop application idea and write it up as a GitHub issue in

OpenHands/agent-canvas

. Here's what was done: ✅ Request fully addressed 1. ✅ Summarized the discussion thread — Distilled the multi-person Slack conversation into a structured issue covering the core proposal, motivation, UX flow, sandboxing strategy, and open questions. 2. ✅ Created a GitHub issue in OpenHands/agent-canvas — Issue #348: "Desktop app experience: zero-friction startup with configurable sandboxing" Changes made • No code changes — this was purely an issue-creation task. A single GitHub API call was made to create the issue. Nothing to commit or push. Issue content highlights The issue captures all key discussion points: • Core UX insight: let users decide sandboxing/permissions after startup, not before (mirrors Claude Code / Codex pattern) • Sandboxing: Docker is too heavy for desktop → use OSX-native Seatbelt (linked SDK PR #3186) • Proposed startup flow:

npm run dev

works immediately, defaults to confirmation mode, users configure via UI • Security modes table: four tiers from auto-approve to Docker sandbox • Open questions: UI before backend, frontend↔️script communication, LLM security_risk reliability, Electron shell requirements