A limitation with this setup is you can't let your agent/Linux user run containers with docker. Adding a user to the `docker` group effectively grants the user full root privileges [1], so the secure way is to setup docker in rootless mode. It's doable, but in my experience it's hard to setup (I find it complex with podman as well).
> Until I'm shown otherwise it seems like a good compromise
Agreed. In my case I went a long way running the Pi harness in a (simple, rootfull) docker container. As the project I worked on relied on a standardized docker compose stack for local dev and testing, I realized I could automate more if only my agent could use docker. Ultimately, the need for docker for my agent grew when testcontainer [2] was introduced in the project. That's when I finally took the time to setup a VM with incus [3], and now I can let the agent go wild with docker inside the VM.
This is at least one example where more isolation is required. Otherwise, the dedicated Linux user, if it works for you, is by far the easiest and most pragmatic solution IMO.
You just made me realize why I've always considered 'chore' the most ambiguous type. In addition to being loosely defined ("transparent change with zero functionnal impact"?), this one is indeed a word related to emotion. No wonder it has a more subjective meaning than 'fix' or 'feat'.
This is why I never use it and almost always pick 'feat' to please the linter. Because I can't help considering that any change worth committing is improving the quality of the code in one way or the other, and thus a feature.
Some alternative forge are built with decentralization in mind:
- forgejo [1] is working on ForgeFed [2], an extension of ActivityPub (the protocol made popular by Mastodon)
- tangled is built on top of ATproto (the protocol behind Bluesky) [3]
- radicle is rolling their own protocol, more peer-to-peer than federated [4]
- fossil is a broader all-in-one solution: not only a new Version Control System (a replacement for git), but also a forge (has the features of a forge: issues (bug-tracking), PRs, comments, wikis, ...) [5]
The other self-hosted forges such as gitlab, sourcehut, gitea don't have such a high level of decentralization and resilience. It does not make them less good, they are solving different problems, mainly being a easy-to-use self-hosted alternative to proprietary forges. For instance Gitea has Gitea Actions, which is designed to be compatible with GitHub Actions [6], while I don't think running CI/CD workflow in a decentralized way will the priority of projects like tangled or radicle.
And to go one step further, for achieving a profile-per-firefox-window workflow, I suggest to have a look at the underrated extension Sticky Window Containers [0]
While far from being perfect, I find it good enough for keeping things separated, especially when using a desktop/workspace workflow. For example, in workspace/desktop 2 I have a Firefox window opened with the first tab set to "container A", so hitting ctrl-t there opens new tabs with the same container "A", so I'm logged-in for all projects A. In another Firefox window in workspace 3 I work with "business project B" tabs (where I'm logged into different atlassian, github, cloud, gmail, ...)
Then with a Window Manager like i3wm or Sway I set keybinds to jump directly to the window (and workspace), using the mark feature [1]
It's also possible to open websites directly in specific containers so it's flexible. For example on my desktop 8 I have all my AI webchats in "wherever my company pay for it" tabs: `firefox --new-window 'ext+container:name=loggedInPersonnal&url=https://chat.mistral.ai' 'ext+container:name=loggedInBusinessA&url=https://chatgpt.com' 'ext+container:name=loggedInBusinessB&url=https://gemini.google.com' 'ext+container:name=loggedInBusinessB&url=https://claude.ai'`
It's also the only way I found to keep opened multiple chat apps (Teams, Slack, Discord, ...). The alternative electron apps are as resource-hungry, and in my experience never handled multiple accounts well (especially Teams).
The part about permissions with settings.json [0] is laughable. Are we really supposed to list all potential variations of harmful commands? In addition to the `Bash(cat ./.env)`, we would also need to add `Bash(cat .env)`, Bash(tail ./.env)`, Bash(tail .env)`, `Bash(head ./.env)`, `Bash(sed '' ./.env)`, and countless others... while at the same time we allow something like `npm` to run?
I know the deny list is only for automatically denying, and that non-explicitly allowed command will pause, waiting for user input confirmation. But still it reminds me of the rationale the author of the Pi harness [1] gave to explain why there will be no permission feature built-in in Pi (emphasis mine):
> If you look at the security measures in other coding agents, *they're mostly security theater*. As soon as your agent can write code and run code, it's pretty much game over. [...] If you're uncomfortable with full access, run pi inside a container or use a different tool if you need (faux) guardrails.
As you mentioned, this is a big feature of Claude Code Web (or Codex/Antigravity or whatever equivalent of other companies): they handle the sand-boxing.
> Until I'm shown otherwise it seems like a good compromise
Agreed. In my case I went a long way running the Pi harness in a (simple, rootfull) docker container. As the project I worked on relied on a standardized docker compose stack for local dev and testing, I realized I could automate more if only my agent could use docker. Ultimately, the need for docker for my agent grew when testcontainer [2] was introduced in the project. That's when I finally took the time to setup a VM with incus [3], and now I can let the agent go wild with docker inside the VM.
This is at least one example where more isolation is required. Otherwise, the dedicated Linux user, if it works for you, is by far the easiest and most pragmatic solution IMO.
[1] https://docs.docker.com/engine/install/linux-postinstall/#ma... ; https://wiki.debian.org/Docker
[2] https://testcontainers.com/getting-started/
[3] https://linuxcontainers.org/incus/docs/main/