One config to rule all your AI agents: portable (every project, every session), effective (curated writing, routing, skills), and safer (destructive-command guard).
Teams using multiple AI coding agents (Claude Code, Codex, Cursor) face config drift: writing rules, permissions, and skills must be duplicated and kept in sync across agents, repos, and machines. anywhere-agents solves this with a single AGENTS.md that drives all agents, plus composable "packs" for adding rules, skills, or permissions on demand.
What This Does
The repo contains a Python package (packages/pypi/anywhere_agents/) and a thin npm wrapper (packages/npm/bin/anywhere-agents.js). The core is cli.py, which handles bootstrapping, deploying, and applying config to multiple agents. The composer/scripts/ directory holds the pack system: compose_packs.py and compose_rule_packs.py merge pack definitions into per-agent configs.
The skills/ directory contains ready-made skills like implement-review (a staged-diff review loop) and prun (parallel task delegation). The docs/ folder includes render scripts and a full mkdocs site.
How It Is Wired
Execution starts at packages/pypi/anywhere_agents/cli.py. From there, the composer/scripts/packs/ package handles pack resolution. The most-connected module is scripts/packs/__init__.py with 17 importers — it's a hub, so changes there ripple widely. The dispatch module (scripts/packs/dispatch.py) routes pack operations to handlers in scripts/packs/handlers/ (command, hook, permission, skill).
The wiring is straightforward: CLI → composer → pack handlers → filesystem writes. No database, no network calls beyond fetching packs from git refs. The locks.py and transaction.py modules handle file-level locking and atomicity.
How To Use It
Setup: Install via pip (pip install anywhere-agents) or npm. The pyproject.toml and package.json are the dependency manifests.
Configuration: No required env vars. Configuration lives in AGENTS.md and pack YAML files. The bootstrap/ directory contains bootstrap.sh and bootstrap.ps1 for initial setup.
Running it: The entry point is the anywhere-agents CLI. Per the README, the core command is:
A researcher with a LaTeX paper workflow: bootstrap installs the agent-style rule pack (bans ~45 AI-tell words), the implement-review skill for pre-push review, and the prun skill for parallel delegation. One AGENTS.md drives Claude Code on macOS and Codex on Linux without drift.
High - Duplicated code blocks: 11,332 repeated 6-line blocks across 121 files, including cli.py and compose_packs.py. Extract shared helpers.
High - Deep nesting: 26 instances, max indentation depth 10 in cli.py. Use guard clauses.
High - Oversized files: 11 files over 3,000 lines, notably cli.py (3,142 lines). Split by responsibility.
Medium - Broad exception handling: 15 instances of bare except in cli.py and compose_rule_packs.py. Catch specific exceptions.
Medium - File handles opened without context managers: 6 instances in locks.py and await-review.py. Use with open().
SDLC observations: tests exist (64 files) and CI runs via GitHub Actions, but there's no lockfile (docs/requirements.txt is unpinned). Two dependencies are one major version behind (mkdocs-include-markdown-plugin, pymdown-extensions). No committed secrets found.
The Bottom Line
This is a practical, well-documented tool for a real pain point — multi-agent config drift. The core design is sound, but the codebase needs refactoring: the hub module and oversized files will make changes expensive. Worth using if you run multiple agents; worth cleaning up if you plan to extend it.
What the analyser found
Deployment readiness
5/7
✗Container image
✓CI pipeline
✗Lockfile committed
✓Test suite
✓README
✓License
✓No committed secrets
Composition
291 files
Python130
Markdown70
Shell26
YAML19
JSON4
HTML2
ReactDjango
Architecture
Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.
Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.
high3
medium5
low1
Pin third-party GitHub Actions to a commit SHAhigh2 occurrences
A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.
Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.
Commit a lockfile beside the manifesthigh
packages/npm/package.json
manifest with no lockfile in scope
An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.
Fix: Run the package manager once and commit the generated lockfile.
Make CI invoke the test suite it hashigh64 occurrences
.github/workflows
64 test files, no test command in the 4 workflows read
A green check that never executed an assertion is worse than no check, because reviewers trust it.
Fix: Add a test step to the existing workflow rather than a new workflow.
Declare least-privilege permissions for GITHUB_TOKENmedium3 occurrences
.github/workflows/docs-strict-build.yml
3 workflow(s) declare no permissions, 1 of them reference secrets
With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.
Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.
Enable Dependabot or Renovatemedium
3 manifest(s), no update bot configured
Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.
Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.
Gate pull requests on a dependency vulnerability scanmedium
.github/workflows
no dependency scan in CI
This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.
Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.
Set persist-credentials: false on checkoutmedium
.github/workflows/docs-strict-build.yml
checkout keeps the token, then dependencies are installed
The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.
Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.
Pin the resolution so a vulnerable version cannot installmedium8 occurrences
no lockfile, and the declared ranges reach pymdown-extensions@10.7 CVE-2026-67422 (high) +7 more
The range includes versions with published advisories and nothing in the repository records which one was resolved, so two installs a month apart can differ in whether they are vulnerable and neither is reproducible from what is committed.
Fix: Commit the lockfile, which fixes the resolution and makes this answerable.
Set timeout-minutes on the workflow jobslow4 occurrences
.github/workflows/docs-strict-build.yml
4 workflow(s) declare no job timeout
A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.
Fix: Add timeout-minutes with a realistic bound to each job.
Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.