Hi Peter, would you be interested in accepting a PR to implement a fully declarative version of Clawdis?

Basically, I configure my system with nix, so it's fully declarative, to contain drift, and ensure rogue Claudes can't do stuff without traceability/rollback protection.
Getting this working with Clawdis requires some hacks (pointing to binaries in different locations, overriding package managers, config files are all immutable, secrets are inside a secrets manager, etc). Doing this "nicely" to support full declarative config would require some upstream changes (or a fork).

A lot of this only makes sense if you have a fully immutable declarative system (aka nix brainworms), so should be fully isolated from "normal" installs and hidden behind feature flags: it shouldn't "get in the way" of a normal user workflow. If I (ok, lets be honest, claude) implements it well, you won't notice it's there. If you do want to use it, you shouldn't have to use nix either, you could just write a big config file, for example.

I'm thinking:

• hidden behind a feature flag, so that "normal" users without nix-brain can continue using the apps today without any changes
• onboarding flow disabled (since it will be preconfigured declaratively)
• patching the tool loader mechanism to allow tools to be wired up from nix-store locations
• adding a way to read encrypted secrets from an agenix-based secrets config (might not even require code changes)
• settings pages become immutable (although i could add some kind of config joining, so that you can mutate settings, but ephemerally)
• Also fixing some bugs that I found where sessions didn't auto-reset when you hit the context window (not sure if related to nix setup or if it's just a regular bug).

I'll also make (but probably not in Clawdis, somewhere else)

• some kind of devenv.sh/nix support so that the agents can still install their own tools when needed
• a crystallization mechanism so the agents can mutate global config (e.g. installing new tools/packages globally on the system, by making PRs to a repo with nix config)

If you're interested in accepting something like this, that would be great!
Any pointers on the overall project philosophy you have that I can give to the implementing agents to ensure their changes are idiomatic would also be very welcome (or just from existing documentation, they should have read it, but you know how they are).
If you don't want to accept this, that's also fine, I'll probably just fork the project and regularly rebase on upstream then instead.

Claude's technical summary (from our implementation tickets):

Critical upstream blocker:

• pnpm 10 requires "pnpm": { "onlyBuiltDependencies": ["sharp"] } in package.json
• Without this, native modules are silently skipped during install → runtime failures
• Affects all pnpm 10 users, not just Nix

Specific path additions for CommandResolver.preferredPaths():

• /run/current-system/sw/bin (nix-darwin system)
• ~/.nix-profile/bin (user profile)
• /etc/profiles/per-user/$USER/bin (NixOS per-user)
• /nix/var/nix/profiles/default/bin (default profile)

Environment variable overrides:

• CLAWDIS_CONFIG_PATH - config file location
• CLAWDIS_STATE_DIR - mutable state (sessions, logs) separate from immutable config
• CLAWDIS_GATEWAY_BIN / CLAWDIS_MAC_HELPER_BIN - explicit binary paths (bypass PATH resolution)

Bug found during analysis:

• clawdis agent CLI throws on empty config, but gateway auto-synthesizes defaults via makeDefaultPiReply() - inconsistent behavior

Explicitly out of scope for upstream:

• Nix derivations/overlays (my repo)
• home-manager module (my repo)
• agenix secrets wiring (my repo - telegram.tokenFile already works)
• devenv.sh / crystallization (separate tooling)