AI tooling

The whole AI toolkit, in one flake. nix run and go.

nix-ai is the package and config layer for everything AI-coding-related. It packages CLIs that don’t yet have first-party Nix derivations, pins MCP server versions, and exports overlays the rest of the Nix stack consumes. Host-specific provider wiring is intentionally outside nix-ai. If a tool needs to point at a private local LLM gateway, package the tool here, then keep the endpoint and token-source module in the consuming workstation flake. That keeps reusable packaging public and environment topology private.

​

What it does

• Packages Claude Code, the Antigravity (agy) CLI, GitHub Copilot CLI, Cribl and Splunk operator CLIs, and assorted AI tooling
• Tracks the operator CLI sources through the flake lock, so consumers can gate their installation to workstation hosts
• Provides MLX module derivations for Apple Silicon
• Pins a catalog of MCP servers and exposes them as reusable Nix attributes
• Exports an overlay so nix-darwin and nix-home can include AI tools without duplicating logic
• Includes a shell module (devShells.default) for “just give me an AI sandbox” workflows

​

How it fits

​

Configuration surface

nix-ai ships as a reusable flake module with a single knob surface — modules/maintainer-profile.nix. This is the one file a consumer touches to adapt the stack:

• Identity fields (user.fullName, user.trustedOrgs) have maintainer defaults so derived values (e.g. Claude auto-mode trusted-org list) stay internally consistent; override them for your own identity.
• Infrastructure fields (homelab.*, telemetry.*, trustedProjectDirs) default to clean/off/empty, so the module evaluates to a neutral config with zero consumer input — no personal context ships in the flake.

Modules read userConfig via _module.args so nothing outside maintainer-profile.nix needs to import it directly. A consumer overrides values either in their own nix-darwin config (via extraSpecialArgs) or by importing the module and setting options.

​

Secrets and injection

Runtime secrets are never stored in Nix store paths or committed files. Four injection patterns are in use: Source-control credentials use none of these. They are short-lived tokens minted on demand per request and never written to disk — not to the Keychain, not to a .env, and not to a direnv cache, since direnv persists its environment dump on disk and would turn a mint-time credential into a stored one. The Keychain row above covers third-party service keys only; treat any older guidance that routes source-control credentials through it as retired. The Splunk entry is one shared catalog item rendered for Claude, Codex, Qwen, and the Antigravity CLI and IDE surfaces. Antigravity (agy) is the Gemini-family harness; it is not a second Gemini MCP identity. Hermes uses the same Splunk connection through its machine AppRole. Terrakube workload identity applies only to remote Terrakube jobs, not interactive workstation agents. The variable catalog (required vs optional, purpose, source) lives in .env.example at the repo root; a real .env is an opt-in convenience — direct injection is preferred. The local injection runbook is AGENTS.local.md (gitignored).

​

Getting started

​

Related repos