Один уровень управления средой Python для разработчиков и каждый агент кодирования ИИ.

Написано в Go. Один статический двоичный файл, без проскальзывания времени выполнения за пределы python3 (или uv, если доступно).

Приведенный выше GIF реален: venv-manager watch app.py --venv X отслеживает файл, сканирует его импорт с помощью крошечного парсера AST-lite, и устанавливает все, что отсутствует — каждый раз, когда файл изменяется. Направьте его на сценарий, в котором LLM повторяется, и venv сходится, как и код.

Почему

Claude, Codex, Cursor и другие кодирующие агенты уже могут запускать команды оболочки, создавать T3 и запрашивать одобрение перед чувствительными операциями. Чего они не разделяют, так это прочного состояния среды Python.

Песочница защищает машину. venv-manager Защищает рабочий процесс: она предоставляет каждому агенту одинаковые среды, метаданные, историю пакетов и путь восстановления, независимо от клиента, который работает.

Два режима отказа приводили в движение этот инструмент:

1. ** Человеческое разрастание. ** Venvs умножаются на ~, каталоги кэша поглощают GB, синтаксис активации варьируется по оболочке, а клонирование «энв, который работал» означает копирование pip freeze между терминалами.
2. ** Агент расползается.

venv-manager

One Python environment control layer for developers and every AI coding agent.

Written in Go. One static binary, no runtime deps beyond python3 (or uv, if available).

The GIF above is real: venv-manager watch app.py --venv X monitors a file, scans its imports with a tiny AST-lite parser, and pip-installs whatever is missing — every time the file changes. Point it at a script an LLM is iterating on and the venv converges as the code does.

---

Why

Claude, Codex, Cursor and other coding agents can already run shell commands, create a .venv, and ask for approval before sensitive operations. What they do not share is durable Python environment state.

Sandboxing protects the machine. venv-manager protects the workflow: it gives every agent the same environments, metadata, package history and recovery path, independent of the client that happens to be running.

Two failure modes drove this tool:

1. Human sprawl. Venvs multiply across ~, cache directories eat GB, activation syntax varies by shell, and cloning “the env that worked” means copy-pasting pip freeze between terminals.
2. Agent sprawl. AI agents can install into the wrong interpreter, leave partial changes behind, and lose environment context when you switch client or start a new session.

venv-manager solves (1) with a clean CLI and (2) with a shared Model Context Protocol server, a persistent registry, typed snapshots and diffs, reversible package changes, ephemeral venvs with OS-level sandboxing, and a file watcher that keeps a venv in sync with evolving code.

What the agent sandbox does not solve