working-with-nix
Skill127 starsChanged 11 days agoMITView on GitHub
Use when working with Nix flakes, selecting devShells, debugging environment issues, or understanding Nix infrastructure - covers shell selection, environment detection, common commands, and project-specific constraints like pinned Rust versions
- Installs packages
In this repository21 other files it gives its agents.
- AGENTS.mdAGENTS.md
- docs/AGENTS.mdAGENTS.md
- .github/workflows/AGENTS.mdAGENTS.md
- nix/AGENTS.mdAGENTS.md
- proto/AGENTS.mdAGENTS.md
- sdks/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/workflows/CLAUDE.mdCLAUDE.md
- nix/CLAUDE.mdCLAUDE.md
- proto/CLAUDE.mdCLAUDE.md
- sdks/CLAUDE.mdCLAUDE.md
- authoring-specsSkill
- check-ciSkill
- checking-spec-complianceSkill
- reviewing-specsSkill
- smoke-checkSkill
- working-with-worktreesSkill
- writing-agent-docsSkill
- writing-rustSkill
- writing-rust-testsSkill
- writing-typescriptSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 44
After every nixpkgs (flake.lock) bump:
- Very specific: line 64
Verify the binary cache is active: nix config show | grep substituters — should include https://xmtp.cachix.org.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Working with Nix in libxmtp
Quick Shell Selection
| Task | Shell | Entry |
| Local development, agents, iOS | default (ios alias) | dev/nix-shell '...' |
| CI Rust jobs, focused Rust work | rust (wasm alias) | dev/nix-shell --shell rust '...' |
| Local Android work | android | dev/nix-shell --shell android '...' |
| Android CI build jobs, Android release | android-ci (Linux) | NIX_DEVSHELL: android-ci |
| Android CI emulator jobs | android-ci-emulator | NIX_DEVSHELL: android-ci-emulator |
| JavaScript and docs CI | js, js-node, docs | dev/nix-shell --shell js '...' |
Environment Detection
For agent commands, use dev/nix-shell 'just <recipe>'. The project Codex hook
adds this wrapper when trusted. The wrapper caches each evaluated shell
environment by the files that the shells read, so a source edit needs no new
evaluation; dev/nix-shell --refresh ... evaluates again. Nested calls reuse
the same environment only when the worktree, shell, and key match. Do not use
the variables below as proof that a requested shell is current. See
docs/agent-tools.md.
echo $XMTP_NIX_ENV # "yes" if in any Rust-based Nix shell
echo $XMTP_DEV_SHELL # rust, local, android, android-ci, or android-ci-emulatorCritical Constraints
Rust Version is Pinned — Do Not Change
Rust is pinned via flake.nix → rust-manifest (1.97.1 as of 2026-07; check with nix develop .#rust -c rustc --version). All shells use xmtp.mkToolchain. Never modify without project-wide coordination.
Playwright Versions Must Match EXACTLY
The playwright pin in package.json (=X.Y.Z) must equal nixpkgs' playwright version. The js shell provides browsers via PLAYWRIGHT_BROWSERS_PATH (nix/js.nix), and npm playwright looks them up by its own per-version browser revisions — any skew fails WASM tests with browserType.launch: Executable doesn't exist at .../chromium_headless_shell-NNNN/....
After every nixpkgs (flake.lock) bump:
nix eval --raw .#devShells.x86_64-linux.js.PLAYWRIGHT_VERSION
# If it differs from the package.json pin: update the pin, then
# pnpm installiOS Shell is macOS Only
The .#ios shell only works on Darwin. Requires Xcode 16+ for Swift 6.1.
Untracked Files are Invisible to Flakes
git add <new-file> # Then rebuild — flakes only see git-tracked filesCachix
Verify the binary cache is active: nix config show | grep substituters — should include https://xmtp.cachix.org.
Shell Architecture
rust is the core: one Rust toolchain (host, wasm32, the Android ABIs, and
on Darwin the Apple slices), the cargo, proto, and lint tools, Node, pnpm,
Python 3.11, and just. default layers on it (inputsFrom) with editor,
debug, and Swift tools and JDK 21; android takes its core packages and adds
the Android SDK, NDK, emulator, JDK 17, Kotlin, and ktlint. All three merge
shellCommon.rustShellEnv, so a switch between them changes no compiler
variable, and on Darwin all three use Xcode clang with the 11.0 macOS floor.
shell-common.nix → rustToolchain, rustCorePackages, rustShellEnv, rustShellHook
├── rust.nix → the core (also `wasm`)
├── local.nix → default = rust + local tools (also `ios`)
├── android.nix → core packages + Android SDK and NDK
└── android-ci.nix → slim CI shells: SDK, NDK, JDK 21; no Rust (Linux only)
js.nix, js-node.nix, docs.nix → JavaScript and docs (no Rust)Essential Commands
# Enter shells (the wrapper caches each evaluated environment)
dev/nix-shell 'just check' # default shell
dev/nix-shell --shell rust 'cargo check' # Rust core
dev/nix-shell --shell android 'just android check'
dev/nix-shell --refresh true # evaluate again
# Build packages
nix build .#xmtp-sdk-wasm # WASM compiled bindings
nix build .#xmtp-sdk-node-darwin-arm64 # Host-matching .node binary
nix build .#xmtp-sdk-generated # Generated JS/TS bindings
nix build .#xmtp-sdk-node-linux-x64-gnu # Per-target .node (example)
nix build .#android-sdk-libs # All Android targets
nix build .#ios-xcframeworks # iOS release XCFramework (macOS only)
# Explore
nix flake show # List all outputs
nix flake metadata # Show inputs and versions
# Debug
nix develop --show-trace # Verbose error outputPlatform Support
| Platform | Shells Available |
| macOS (aarch64-darwin) | rust, default, android, ios, js, js-node, docs, wasm |
| Linux (x86_64-linux) | rust, default, android, android-ci, android-ci-emulator, js, js-node, docs, wasm |
Key Files
| File | Purpose |
flake.nix | DevShell + package definitions, input pinning, cachix |
nix/lib/default.nix | Overlay wiring — exposes xmtp.* to all Nix files |
nix/lib/shell-common.nix | Shared building blocks (rustBase, wasmEnv, tool groups) |
nix/lib/mkToolchain.nix | Rust version pinning logic |
nix/lib/filesets.nix | Source file filtering for hermetic builds |
nix/lib/android-env.nix | Android SDK config, targets, emulator script |
nix/lib/ios-env.nix | iOS targets, dynamic Xcode resolution |
nix/lib/napiTarget.nix | Rust target triple to NAPI target name mapping |
nix/lib/packages/pnpm.nix | Workspace pnpm package; version comes from root package.json |
nix/shells/rust.nix | Rust core shell (also wasm) |
nix/shells/local.nix | Local dev shell (default, also ios) |
nix/shells/android.nix | Local Android shell |
nix/shells/android-ci.nix | Slim Android CI shells (Linux) |
nix/js.nix | JavaScript shell |
nix/package/node.nix | Node.js per-target builds + JS/TS generation |
nix/package/xmtp-sdk-native.nix | Native SDK release build derivation |
nix/package/ios.nix | iOS release build derivation |
dev/nix-up | Installation script for Nix, the binary cache, and direnv |
.node-version, .nvmrc | Node.js version for tools outside Nix |
Further Reference
- Shell: Default — Full local dev shell reference
- Shell: Rust — Focused Rust shell reference
- Shell: Android — Android shells reference
- Shell: JavaScript — JavaScript shell reference
- Nix Build Packages — All
nix build .#<package>outputs - Troubleshooting — Common issues and solutions
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

