build: add nix flake packaging

[ReStranger]

What / Why / How

Add Nix flake packaging for context-mode so the project can be built and run as a Nix package instead of only via npm-style installation. This adds a minimal flake-based package that wraps the bundled CLI with nodejs_22, includes the runtime assets the CLI expects next to itself, enables allowUnfree in the flake-local Nixpkgs import for the project's Elastic-2.0 license, and exposes the package as both packages.default and packages.context-mode plus an apps.default entry for nix run.

Affected platforms

• Claude Code
• Cursor
• VS Code Copilot (GitHub Copilot)
• Gemini CLI
• OpenCode
• KiloCode
• Codex CLI
• OpenClaw (Pi Agent)
• Kiro
• Antigravity
• Zed
• All platforms

Test plan

• Build the package with nix build .#context-mode
• Run ./result/bin/context-mode --help
• Run ./result/bin/context-mode doctor
• Run nix run .# -- --help
• Verify bundled runtime detection includes node, tsx, and python3 from the wrapped PATH

Checklist

• Tests added/updated (TDD: red → green)
• npm test passes
• npm run typecheck passes
• Docs updated if needed (README, platform-support.md)
• No Windows path regressions (forward slashes only)
• Targets next branch (unless hotfix)

Cross-platform notes

Our CI runs on Ubuntu, macOS, and Windows.

• This change does not modify application path handling logic; it only adds Nix packaging metadata and a wrapper script
• The package uses the prebuilt cli.bundle.mjs and installs runtime assets alongside it, matching the existing relative-path expectations in the CLI
• nodejs_22 is used so Linux builds can rely on the built-in SQLite path already supported by the project
• allowUnfree is configured in the flake's local nixpkgs import, so users do not need --impure or external Nix config to build the package

[mksglu]

Hey @ReStranger, thanks for putting this together! 🙏

After review, we've decided not to merge this. Here's why:

1. context-mode is an MCP server, not a standalone CLI

context-mode runs as an MCP server spawned by AI coding tools (Claude Code, Gemini CLI, Cursor, etc.) via their plugin/MCP systems. It's not a standalone binary users invoke directly. The install flow is:

• Claude Code: npx context-mode@latest setup or marketplace install
• Gemini CLI: npx context-mode@latest setup --adapter gemini-cli
• OpenCode/Kilo: plugin in opencode.json

A Nix package would build a standalone binary, but no AI coding tool knows how to discover or spawn it from a Nix store path. The tool would be installed but unreachable.

2. Hardcoded version creates immediate drift

version = "1.0.89" in package.nix — we're already at 1.0.89+ and releasing frequently. This would be stale on day one and require manual bumps on every release.

3. Placeholder description

description = "Description for the project" in flake.nix — suggests this wasn't fully polished.

4. Maintenance burden

4 new files (flake.nix, flake.lock, nix/package.nix, .gitignore change) that need updating on every release, but zero maintainers use Nix. Untested packaging rots fast.

5. allowUnfree = true concern

The flake sets config.allowUnfree = true globally for the Nixpkgs import. context-mode uses Elastic License 2.0 which has specific restrictions — this flag silently bypasses Nix's license compliance checks in a way that could surprise downstream consumers.

If there's genuine demand for Nix packaging, the right approach would be a community-maintained flake in a separate repo (like nix-community/) that we can link to from our docs. That way the packaging can evolve independently without blocking our release cadence.

Thanks again for the effort — hope to see you on future PRs!