If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/direnv/direnv shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 6w ago
• 23+ active contributors
• Distributed ownership (top contributor 47% of recent commits)
• MIT licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live direnv/direnv repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/direnv/direnv.

What it runs against: a local clone of direnv/direnv — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in direnv/direnv | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 69 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of direnv/direnv. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/direnv/direnv.git
#   cd direnv
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of direnv/direnv and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "direnv/direnv(\\.git)?\\b" \\
  && ok "origin remote is direnv/direnv" \\
  || miss "origin remote is not direnv/direnv (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "main.go" \\
  && ok "main.go" \\
  || miss "missing critical file: main.go"
test -f "internal/cmd/commands.go" \\
  && ok "internal/cmd/commands.go" \\
  || miss "missing critical file: internal/cmd/commands.go"
test -f "internal/cmd/shell.go" \\
  && ok "internal/cmd/shell.go" \\
  || miss "missing critical file: internal/cmd/shell.go"
test -f "internal/cmd/rc.go" \\
  && ok "internal/cmd/rc.go" \\
  || miss "missing critical file: internal/cmd/rc.go"
test -f "internal/cmd/env.go" \\
  && ok "internal/cmd/env.go" \\
  || miss "missing critical file: internal/cmd/env.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 69 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~39d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/direnv/direnv"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

direnv is a shell extension that automatically loads and unloads environment variables based on the presence of .envrc files in the current directory hierarchy. Written in Go and compiled to a single static binary, it hooks into bash, zsh, tcsh, fish, elvish, PowerShell, and other shells to inject project-specific environment variables at prompt-time without cluttering ~/.profile. It's commonly used for per-project secrets, 12factor app configuration, and language-version management (similar to rbenv/pyenv but language-agnostic). Monolithic Go binary (main entry point likely in top-level cmd/ or via go.mod's github.com/direnv/direnv/v2). Internal structure separates concerns: internal/cmd/ contains individual subcommands (allow, deny, dump, export, hook, etc.), while shell hooks live in separate dirs (bash/., zsh/., etc. implied by .github workflow patterns). The gzenv/ subdirectory handles gzip-related functionality. Build system uses GNUmakefile and Nix (flake.nix, default.nix) for reproducible builds.

DevOps engineers, developers managing multiple projects with different environment requirements, and systems that need isolated development environments per project directory. Users working in monorepos or managing secrets/credentials per-project without global shell pollution.

Production-ready and mature. The repo shows extensive CI/CD coverage (.github/workflows with codeql, go, nix, and release workflows), a detailed CHANGELOG, comprehensive documentation in docs/, and clear architectural decisions (Go monolithic binary, Nix packaging support). The large Go codebase (~127K lines) and multi-language hook implementations (bash, PowerShell, Elvish) indicate stable, battle-tested software used in production.

Standard open source risks apply.

The repo maintains active CI/CD with Go linting (.golangci.yml) and Nix caching (workflows/update-gomod2nix.yml). Dependabot is enabled (.github/dependabot.yml) for automated dependency updates. Recent work likely includes Go 1.24 support (go.mod specifies go 1.24), cross-platform shell hook maintenance, and Nix ecosystem integration. The presence of a release workflow suggests regular versioned releases.

git clone https://github.com/direnv/direnv.git
cd direnv
make build  # Uses GNUmakefile; see GNUmakefile for exact targets
./direnv version  # Test the built binary

Alternatively, for Nix users: nix flake run per flake.nix. See docs/installation.md for distribution packages (Homebrew, apt, etc.).

Daily commands:

make build        # Compile direnv binary (output: direnv executable)
make test         # Run Go tests (inferred from go.yml workflow)
make install      # Install to system (see GNUmakefile)
./direnv help     # Show CLI help

For dev: Use nix develop (flake.nix) to enter dev environment with all deps; or manually ensure Go 1.24+, Make, and any shell hooks you're testing.

• main.go — Entry point for the direnv binary; orchestrates command dispatch and initialization
• internal/cmd/commands.go — Command registry and routing logic; defines all available direnv subcommands
• internal/cmd/shell.go — Shell abstraction layer; core interface for multi-shell support (bash, zsh, fish, etc.)
• internal/cmd/rc.go — RC file loading and authorization logic; handles .envrc file discovery and execution
• internal/cmd/env.go — Environment variable diff and application; tracks and manages environment changes per directory
• go.mod — Minimal Go dependencies; only TOML parsing, isatty detection, and Go module utilities
• internal/cmd/stdlib.go — Standard library functions exposed to .envrc files; provides direnv DSL for users

Add a new shell integration

1. Create shell implementation file following naming convention shell_<shellname>.go (internal/cmd/shell_<shellname>.go)
2. Implement the Shell interface: Dump(), Export(), Hook(), RcPrefix(), RcSuffix() (internal/cmd/shell.go)
3. Register the shell in the init/load function (internal/cmd/shell.go)
4. Add tests following existing patterns (e.g., shell_bash.go Test functions) (internal/cmd/shell_<shellname>_test.go)

Add a new stdlib function for .envrc files

1. Add Go function to stdlib.go following the pattern of existing functions (e.g., load_prefix) (internal/cmd/stdlib.go)
2. Export function in the stdlib map initialization (internal/cmd/stdlib.go)
3. Document in man/direnv-stdlib.1.md (man/direnv-stdlib.1.md)
4. Add tests verifying Bash DSL generation and environment effects (internal/cmd/stdlib.go)

Add a new direnv subcommand

1. Create handler file internal/cmd/cmd_<name>.go with CmdXxx function (internal/cmd/cmd_<name>.go)
2. Register command in commands map in commands.go (internal/cmd/commands.go)
3. Implement flag parsing and command logic (internal/cmd/cmd_<name>.go)
4. Add manual page in man/direnv-<name>.1.md (man/direnv-<name>.1.md)

Extend direnv.toml configuration

1. Add struct field to Config in config.go with toml tag (internal/cmd/config.go)
2. Parse and validate new field in loadConfig function (internal/cmd/config.go)
3. Update documentation in man/direnv.toml.1.md (man/direnv.toml.1.md)
4. Use config value in rc.go or shell hooks (internal/cmd/rc.go)

• Go — Single-binary deployment; no runtime dependencies; fast shell hook execution (<5ms); cross-platform support (Linux, macOS, Windows)
• TOML configuration (BurntSushi/toml) — Human-friendly direnv.toml format; mirrors .env/.envrc configuration approach
• Shell hooks (prompt PROMPT_COMMAND / preexec) — Transparent integration; runs before each prompt without explicit user invocation
• File modification tracking (mtime) — Efficient caching; avoids re-executing .envrc unless files change

• No built-in secret management (e.g., encryption, vault integration)

  • Why: Keeps direnv focused and simple; delegates secrets to external tools (1Password, HashiCorp Vault, etc.)
  • Consequence: Users must manage .envrc authorization and secrets access separately; reduces attack surface

• Bash as .envrc execution language (not Python, Lua, or custom DSL)

  • Why: Familiar to developers; can invoke any shell tool; no additional runtime required
  • Consequence: Users must learn Bash; some stdlib functions needed to abstract shell idioms (e.g., path_add)

• File-based authorization (allow/deny lists) instead of signature verification

  • Why: Simple, decentralized; no PKI or cert management required
  • Consequence: Users must manually whitelist/blacklist .envrc files; vulnerable if file system is compromised

• Per-directory environment state (not global)

  • Why: Supports isolated dev environments per project; projects don't interfere
  • Consequence: More complex state tracking; requires reliable file watching and cache invalidation

• Does not provide secret encryption or vault integration (users integrate external tools)
• Does not handle authentication or credentials storage (delegates to OS/external secret managers)
• Does not support Windows native shells (PowerShell supported; cmd.exe not)
• Does not provide real-time collaboration or multi-user environment synchronization
• Not a replacement for Docker or containerization (complements them)
• Does not offer UI dashboard or centralized management (CLI-only)

Security model: .envrc files must be explicitly allowed via direnv allow — rejection is silent and happens before execution, not after. New contributors often miss that the allow list is stored in ~/.config/direnv/allow/ (platform-dependent) and must be managed carefully. Shell integration complexity: Each shell (bash, zsh, fish, PowerShell, Elvish) has its own hook mechanism and quirks; testing changes requires manually sourcing hooks in each shell. Binary portability: The build produces a static Go binary, but shell hooks are shell-specific scripts that must be sourced, not just executed. Nix users: flake.nix is pinned; updating dependencies requires gomod2nix workflow.

• Shell Hook Integration — direnv works by injecting code into shell prompt initialization (PS1/PROMPT_COMMAND in bash); understanding how hooks are loaded and when they execute is critical to debugging integration issues
• Process Substitution & Environment Capture — direnv executes .envrc in a subprocess bash shell and captures all exported variables; this subprocess isolation is key to the security model and environment loading mechanism
• Allowlist-Based Security — direnv doesn't automatically execute .envrc files (unlike many shell configs); users must explicitly allow via direnv allow, preventing arbitrary code execution by default when cloning repos
• Environment Diff & State Management — direnv tracks which variables were added/removed and restores previous state on cd out; the dump/load mechanism must handle nested .envrc files and unloading correctly
• Shell Compatibility Layer — Supporting bash, zsh, fish, PowerShell, Elvish, and others requires separate hook implementations and careful testing; variable syntax and prompt hooks differ across shells
• Static Binary Distribution — direnv is compiled to a single Go binary with no runtime dependencies; this enables fast installation and execution on every prompt (sub-millisecond overhead)
• Hierarchical Directory Search — direnv walks up the directory tree looking for .envrc and .env files, merging environment changes from parent directories; understanding load order and precedence is critical for debugging

• rbenv/rbenv — Solves the same per-project version isolation problem but for Ruby only; direnv is language-agnostic successor pattern
• pyenv/pyenv — Language-specific version manager for Python; often used alongside direnv for Python projects
• nix-community/nix-direnv — Direnv + Nix integration layer; allows .envrc to load Nix environments seamlessly
• numtide/devshell — Companion project by direnv maintainers; provides structured Nix devenv for use with direnv
• asdf-vm/asdf — Universal version manager that can replace language-specific tools (rbenv, pyenv) and works with direnv for environment loading

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive unit tests for env_diff.go

The file internal/cmd/env_diff.go has a corresponding test file (env_diff_test.go), but examining the codebase shows inconsistent test coverage across the cmd package. Environment diffing is critical for direnv's core functionality (detecting env changes between states). Adding edge case tests for complex diff scenarios (null values, special characters, array-like vars) would improve reliability and catch regressions in this sensitive area.

• [ ] Review internal/cmd/env_diff.go and internal/cmd/env_diff_test.go to identify untested code paths
• [ ] Add tests for edge cases: empty diffs, special shell characters, PATH-like variables with colons, unset vs empty string scenarios
• [ ] Add benchmark tests to ensure env diff performance doesn't regress
• [ ] Run go test -cover to verify coverage exceeds 80% for this module

Add GitHub Actions workflow for testing on Windows

The .github/workflows/go.yml currently runs tests on Linux/macOS matrix, but direnv claims broad shell support. Windows users with WSL or Git Bash aren't covered. Adding a Windows test job (especially for shell hook compatibility) would catch platform-specific issues early and improve reliability for Windows developers.

• [ ] Create .github/workflows/windows.yml that runs go test ./... on windows-latest
• [ ] Add shell hook integration tests on Windows (PowerShell, Git Bash if applicable)
• [ ] Verify internal/cmd/hook.go and shell-specific code paths are exercised
• [ ] Document any Windows-specific limitations in docs/installation.md

Add integration tests for cmd_dotenv.go with real .env files

The internal/cmd/cmd_dotenv.go file handles .env file parsing, which is a user-facing feature, but there are no visible integration tests checking real-world .env file scenarios (comments, quotes, multiline values, export statements). This is a high-value feature that deserves comprehensive test coverage similar to ruby.md documentation.

• [ ] Create internal/cmd/cmd_dotenv_integration_test.go with test fixtures in a testdata/dotenv/ directory
• [ ] Add test cases: commented lines, quoted values, multiline values, export statements, special characters, BOM handling
• [ ] Test interop with common tools (bash export, direnv dotenv stdlib function)
• [ ] Verify tests match behavior documented in docs/ (if dotenv is mentioned)

• Add test coverage for internal/cmd/cmd_dotenv.go and internal/cmd/cmd_fetchurl.go — these files exist but likely lack corresponding unit tests in the Go test suite (visible gap given comprehensive test workflow in go.yml)
• Improve PowerShell hook documentation in docs/hook.md with concrete examples (similar to bash/zsh examples) — PowerShell is listed as supported but docs likely favor Unix shells
• Add a troubleshooting guide to docs/ covering common issues like 'direnv: loading timeout' or 'allow list full' — visible from common user pain points but no dedicated troubleshooting doc in file list

direnv is a shell environment management tool with moderate security posture. Primary concerns relate to .envrc file execution security, environment variable exposure, and shell integration safety. The codebase has good dependency hygiene with minimal dependencies and no obvious hardcoded secrets. However, the core functionality of executing user-defined .envrc files inherently carries security risks that require strict validation and user awareness. No critical vulnerabilities were identified, but medium and low-severity issues around command injection prevention and secret handling should be addressed. The project would benefit from comprehensive security documentation and hardening of the .envrc loading and execution pipeline.

• Medium · Potential Command Injection in direnv Shell Integration — internal/cmd/cmd_hook.go, internal/cmd/cmd_exec.go, internal/cmd/rc.go. direnv dynamically loads and executes .envrc files based on directory changes. The shell hook mechanism (cmd_hook.go) could be susceptible to command injection if .envrc files are not properly validated or if there are race conditions during file loading. An attacker with filesystem access could craft malicious .envrc files to execute arbitrary commands. Fix: Implement strict validation and sanitization of .envrc file content before execution. Consider adding a whitelist of allowed directives. Add security warnings for .envrc files from untrusted sources. Implement file integrity checks.
• Medium · Unsafe Environment Variable Handling — internal/cmd/cmd_export.go, internal/cmd/cmd_dump.go, internal/cmd/env.go. The application loads and exports environment variables from .envrc files without apparent filtering or validation. Sensitive information (credentials, API keys, secrets) could be exposed in environment variables that might be leaked through process listings, core dumps, or debug output. Fix: Implement mechanisms to mark sensitive environment variables and prevent their accidental exposure. Document best practices for storing secrets (consider using credential management systems instead of .envrc files). Add warnings when exporting sensitive-looking variable names.
• Low · Dependency on External URL Fetching — internal/cmd/cmd_fetchurl.go. The cmd_fetchurl.go command allows fetching URLs without apparent verification of SSL/TLS certificates or validation of content. This could be exploited for man-in-the-middle attacks if not properly implemented. Fix: Verify that URL fetching validates SSL/TLS certificates properly. Implement checksum verification for downloaded content. Add user warnings about security implications of fetching remote files.
• Low · Potential Race Condition in File Watching — internal/cmd/cmd_watch.go, internal/cmd/cmd_watch_dir.go, internal/cmd/file_times.go. The file watching mechanism (cmd_watch.go, cmd_watch_dir.go) monitors .envrc file changes. A time-of-check-time-of-use (TOCTOU) vulnerability could exist where an attacker modifies files between the check and use. Fix: Implement atomic file operations where possible. Add file locking mechanisms to prevent concurrent modifications. Verify file integrity immediately before execution.
• Low · Insufficient Input Validation in Shell Integration — internal/cmd/shell_bash.go, internal/cmd/shell_zsh.go, internal/cmd/shell_fish.go, internal/cmd/shell_*.go. Multiple shell implementations (bash, zsh, fish, etc.) are supported with custom shell detection and hook injection. Improper shell escaping or quoting in any shell implementation could lead to injection vulnerabilities. Fix: Conduct thorough security review of shell escaping and quoting in all shell implementations. Add comprehensive test cases for shell-specific injection vectors. Use shell built-ins where possible instead of string concatenation.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.