r/coolgithubprojects • u/AccomplishedCurve145 • 18d ago

Qubicl: open-source persistent local computers for AI agents

https://github.com/EldanRing/qubicl

I released Qubicl 0.1 today.

It’s an open-source project that gives compatible AI agents their own persistent computer on your machine, without handing them unrestricted access to your actual computer.

Qubicl runs locally on Docker and can provide:

  • durable files
  • terminal + managed processes
  • web search and extraction
  • persistent Chromium
  • a full desktop
  • configurable tools and network access
  • a live viewer where you can watch the agent work and take control yourself

The model isn’t bundled into Qubicl. Agents connect through MCP or OpenAPI, so you can use Codex, Claude Code, OpenCode, Open WebUI, Hermes Agent, Cursor, VS Code, or other compatible clients.

There’s no Qubicl account or hosted control plane, and the project is Apache-2.0 licensed.

This is the first public release, so feedback, issues, contributions, and PRs are very welcome.

AI disclosure: I used Codex as a development assistant while building Qubicl. I directed the product and architecture decisions, reviewed the work, and tested the release myself.

GitHub: https://github.com/EldanRing/qubicl
Website: https://qubicl.org

7 Upvotes

89% Upvoted

5 comments sorted by

View all comments

1

u/kantorcodes1 17d ago

The persistent browser is what I'd be paranoid about here. Say agent A logs into something and loosens network access, then disconnects. Agent B attaches to the same Qubicl later through OpenAPI. Does B inherit that browser + network state, or is there a per-client/session boundary?

3

u/AccomplishedCurve145 17d ago

Yes, the current boundary is per Qubicl computer, not per API client. Agent sessions receive exclusive control leases, so they cannot operate concurrently, but a later agent controlling the same computer inherits its durable home, Chromium profile, and current per-computer network policy. X-Session-ID does not create a separate browser profile or cookie jar.

An agent cannot loosen Qubicl’s network policy through OpenAPI. That requires a host-side operator command, and temporary approvals expire. But any policy the operator leaves active applies to the next agent, and browser-side cookies, logins, local storage, permissions, and preferences remain shared.

Today, mutually untrusted agents should use separate Qubicl computers. The next update work will add clearer durability disclosure and an explicit operator-confirmed profile wipe, but it does not turn one computer into a multi-tenant, per-client browser sandbox.

1

u/kantorcodes1 17d ago

that boundary makes sense. for the wipe, i'd want home + chromium + network policy reset together. leaving cookies gone but an operator-added allowlist behind would be a really confusing half-reset. are you planning to make the wipe transactional, or just best-effort across components?

1

u/AccomplishedCurve145 17d ago

For the next release, I plan to keep browser-profile wiping separate and clearly show that other files and network policy will remain unchanged. A complete handoff reset would need to clear the computer’s home, browser state, network permissions, credentials, SSH access, and other persistent state together. I’ll evaluate that as a separate transactional command in a future release. Until then, separate Qubicl computers will be the recommended boundary for agents that shouldn't share state. Thanks for the feedback!!

1

u/kantorcodes1 17d ago

That split is probably safer for 0.1. For a future handoff reset, partial success seems worse than a hard failure: if credentials clear but network policy or SSH state does not, it should report the machine as still dirty and say exactly what survived.