{"slug": "lanegate-git-native-worktree-orchestrator-for-ai-agents", "title": "LaneGate – Git-native worktree orchestrator for AI agents", "summary": "LaneGate, a new open-source git-native worktree orchestrator, coordinates AI coding agents like Claude, Codex, Ollama, and aider by giving each ticket its own git worktree, enforcing file-level locks, and requiring approved reviews before merging to main. It re-runs pre_merge guards against the merged result to catch conflicts that pass in isolation, and it does not sandbox agents at the OS level in V1. The tool is designed to prevent half-baked merges and edit collisions in multi-agent repositories.", "body_md": "**Parallel lanes. Protected gates.**\nEvery agent gets a lane. Nothing ships without a gate.\n\nLaneGate coordinates coding agents (Claude, Codex, Ollama, aider, etc.) working on one repo: every ticket gets its own git worktree, declared `touches`\n\nlock the files a ticket owns so a second agent can't claim them, and nothing reaches `main`\n\nwithout an approved review plus whatever guards you configure. Tickets are Markdown files in your repo. No SaaS, no external project state.\n\n**You want this if** you've watched an agent merge something half-baked and found out two commits later, or you've had two agents clobber each other's edits in the same checkout.\n\nThe part most tools skip: `pre_merge`\n\nguards re-run *against the merged result*, not just the ticket's branch. Two tickets that each passed in isolation but break once combined get caught here — LaneGate resets `main`\n\nto its pre-merge commit and routes the ticket back to review instead of leaving a broken commit behind.\n\nLaneGate doesn't plan or implement. Your agents and IDE do that; LaneGate runs the gate around them.\n\nSecurity note.V1 provides git-level isolation and diff inspection. It does not sandbox agents at the OS level. Agents run as host processes. See[Security Status]and[Known Limitations]before running it on repositories you care about.\n\n- keep agent work as local Markdown tickets\n- run each task in its own git worktree\n- reduce edit collisions with explicit file-level\n`touches`\n\n- block out-of-scope or sensitive-file changes from auto-merge\n- run configured safeguards before completion or merge\n- pause for human review before anything lands on\n`main`\n\nBy default, LaneGate commits ticket specs and review verdicts to git as they change. Tickets are a git-native artifact, not local-only state. Executor transcripts, logs, cooldowns, locks, and worktrees stay local under `.lanegate/`\n\n. Set `commit_status_changes: false`\n\nto opt back into fully zero-footprint local state.\n\nMCP is built in. Run `lanegate mcp`\n\nto expose LaneGate commands as native tools for any MCP-compatible agent (Claude, Cursor, etc.), with no shell commands required.\n\n```\n.lanegate/tickets/TICK-007.md   ← source of truth (YAML frontmatter)\n        │\n        ▼\nlanegate next         ← agent asks: what should I work on?\nlanegate start TICK-007  ← agent claims it; worktree + branch created\n  ... agent works in .lanegate/worktrees/tick-007/ ...\nlanegate complete TICK-007\nlanegate review TICK-007\nlanegate merge TICK-007   ← branch → main, worktree removed\nlanegate promote production  ← staged deploy with guard/pre/post hooks\n```\n\nMain command groups:\n\n| Group | Commands |\n|---|---|\nScoping: record work as tickets and ask an executor to infer `touches` / `close_criteria` |\n`create` , `analyze` |\nExecution: who works on what without colliding |\n`board` , `next` , `start` , `complete` , `review` , `merge` |\nDelivery: how merged code reaches environments |\n`promote` , `pipeline-status` , `flag` |\n\nThat's the happy path. For the full state machine — every status, what blocks each transition, where a ticket lands when a guard or review fails, and how many review rounds run — see [docs/lifecycle.md](/sudheerdvn/lanegate/blob/main/docs/lifecycle.md).\n\nLaneGate is experimental software for coordinating coding agents on a local repo. Before letting it run without review, read this section.\n\n**What LaneGate does to limit agent scope:**\n\n- Runs each agent in a dedicated git worktree, one per ticket\n- Enforces a\n`touches`\n\nlist: files committed outside the declared scope route to`needs_review`\n\n- Hard-blocks writes to CI/CD configs, dependency manifests (Python, JS/Node, Rust, Go, Java/Gradle, Ruby, PHP, .NET), and credential-shaped files (\n`.env`\n\n,`*.pem`\n\n,`secrets.*`\n\n) - Scans ticket text for prompt injection signals before dispatch\n- Optionally runs gitleaks, semgrep/bandit, pip-audit, npm-audit, composer-audit, and bundler-audit on agent-produced diffs\n- Runs configured\n`safeguards`\n\nsuch as tests or scripts before`complete`\n\nand`merge`\n\n**What LaneGate does NOT do:**\n\n- MCP is not a sandbox.\n`lanegate mcp`\n\nexposes ticket lifecycle commands as native tools, and an agent with access to those tools can claim tickets, create branches, and trigger merges. The MCP server authenticates nothing beyond what the MCP client config enforces. - Host executors inherit host permissions. Agents (Claude Code, aider, Codex) run as the invoking OS user with full filesystem and network access. There is no bwrap, seccomp, or container wrapping.\n- The file-based lock is single-machine, single-checkout. Two separate clones on two machines can both claim the same ticket.\n- File-level locks are not semantic dependency analysis. Two tickets can touch different files and still break each other through shared APIs, imports, types, schemas, or runtime behavior. Treat\n`touches`\n\nas a practical coordination boundary, not a proof of correctness.\n\n**Recommendation:** use `--human-review final`\n\nwhen running `lanegate run`\n\non any repository with production code. This stops after implementation and requires `lanegate merge <id>`\n\nto be run manually after you inspect the diff. To make this the safe default without depending on every invocation remembering the flag, set `default_human_review: final`\n\n(or `per_ticket`\n\n) in `.lanegate.yml`\n\n. An explicit `--human-review`\n\nflag still overrides it. Note that a ticket's `autonomy`\n\nfield also gates the merge step: the default `autonomy: supervised`\n\nalready pauses every approved ticket for a human merge decision regardless of `--human-review`\n\n, and unattended merge only happens when both `--human-review none`\n\nand `autonomy: full`\n\n/`green`\n\n/`yellow`\n\napply — see [docs/config-reference.md](/sudheerdvn/lanegate/blob/main/docs/config-reference.md#--human-review-reference) for the full breakdown.\n\nFor the full threat model, executor permissions, and safe usage notes, see [SECURITY.md](/sudheerdvn/lanegate/blob/main/SECURITY.md) and [docs/security-model.md](/sudheerdvn/lanegate/blob/main/docs/security-model.md).\n\n**Lock scope is single-machine, single-checkout.** The file-based concurrency lock at`.lanegate/orchestrator.lock`\n\nprevents two`lanegate run`\n\nruns on the same checkout from racing, but does not coordinate across separate clones or machines.**No OS-level sandbox in V1.** Agents run as child processes with full user permissions (no bwrap, seccomp, or container wrapping), regardless of which Claude Code permission mode is configured (see the next bullet for that separate, application-level choice). LaneGate inspects the git diff after the agent exits. It cannot observe what the agent read or sent over the network during execution.**Executor permissions come from the executor runtime, not from LaneGate.**`lanegate init`\n\nconfigures Claude Code with a scoped`--allowedTools`\n\nset by default so the agent can run headless without interactive prompts, while tools outside that list stay gated. You can instead configure`flags: [\"--dangerously-skip-permissions\"]`\n\n, which disables Claude Code's per-action approval prompts entirely. That's a valid choice for setups like a sandboxed CI runner, but it means the agent acts on anything without confirmation. See[Security Status](/sudheerdvn/lanegate/blob/main/docs/security-model.md#headless-permission-options-for-the-claude-executor)for the full set of options.\n\n| Platform | Status |\n|---|---|\n| Linux | Supported, primary development platform |\n| macOS | Supported, CI-verified on every push |\n| Windows | Core functionality works, but projects using `.sh` executor scripts require WSL |\n\n```\npip install lanegate\nlanegate init    # scaffold .lanegate/ + .lanegate.yml in your repo\n```\n\n`lgt`\n\nand `lane`\n\nare installed alongside `lanegate`\n\nas short aliases for the same command (e.g. `lgt board`\n\n, `lane run`\n\n). Use `lanegate run`\n\n(or `lane run`\n\n) to clear the board; `lanegate orchestrate`\n\nremains a compatibility alias. If you added `lane`\n\nto an existing editable install, run `pip install -e .`\n\nonce to create the new executable.\n\nTicket analysis matches candidate files by parsing real symbols — via stdlib `ast`\n\nfor Python and built-in tree-sitter support for JS/TS, Go, Rust, Java, Ruby, C, and C++. Multi-language symbol parsing is available with every LaneGate installation.\n\nLaneGate is a standalone CLI, not a library you import into a project. [pipx](https://pipx.pypa.io/) is the recommended way to install it, since it isolates the tool's own dependencies from whatever Python environment your project uses:\n\n```\npipx install lanegate\nlanegate init\n```\n\nTo run from source:\n\n```\ngit clone https://github.com/sudheerdvn/lanegate\ncd lanegate\npip install -e \".[dev]\"\n```\n\nCommit what `lanegate init`\n\nscaffolded (`.lanegate.yml`\n\n, `.gitignore`\n\n, `.lanegate/`\n\n) before creating your first ticket — ticket worktrees are created with `git worktree add`\n\n, which only ever sees committed content, so an uncommitted `.gitignore`\n\nmeans the first ticket's worktree has none at all:\n\n```\ngit add .lanegate.yml .gitignore .lanegate/\ngit commit -m \"chore: scaffold LaneGate\"\n```\n\nFor real repositories, configure safeguards before you let an executor run. Safeguard commands run in your project's own environment, not LaneGate's, so make sure the test runner is actually installed there first (e.g. `pip install pytest`\n\nin a fresh venv) or `pre_complete`\n\nfails before the executor gets a chance to do anything:\n\n```\nsafeguards:\n  pre_complete:\n    - pytest\n  pre_merge:\n    - pytest\n  post_merge:\n    - pytest\n# 1. Create a ticket file\ncat > .lanegate/tickets/TICK-001.md << 'EOF'\n---\nid: TICK-001\ntitle: Add rate limiting to the upload endpoint\nstatus: open\npriority: 1\ntouches:\n  - src/upload.py\n  - src/middleware.py\nparallel_safe: true\nautonomy: supervised\nclose_criteria: POST /upload returns 429 after 100 requests/min per user\n---\n\n## Background\nA single client can saturate the worker pool with rapid uploads.\nEOF\n\n# 2. See the board\nlanegate board\n\n# 3. Agent claims and works\nlanegate start TICK-001\n# ... implement in .lanegate/worktrees/tick-001/ ...\nlanegate complete TICK-001\nlanegate review TICK-001\nlanegate merge TICK-001\nlanegate validate TICK-001\nlanegate done TICK-001\n\n# 4. Deploy\nlanegate promote production\nlanegate board                    # see the ticket board and pipeline snapshot\nlanegate next                     # choose the next unblocked ticket(s)\nlanegate create \"Add rate limits\" --title \"Rate-limit uploads\" --autonomy supervised\nlanegate start TICK-007           # claim; creates branch + worktree\nlanegate complete TICK-007        # code done → code_complete\nlanegate review TICK-007          # submit for review → in_review\nlanegate merge TICK-007           # merge to main, delete worktree → merged\nlanegate run                      # clear eligible work with the configured executor\n```\n\nThat covers daily use. For planning/reporting, the full ticket lifecycle, deployment,\nfeature flags, MCP, the local API/UI, the TUI, monitoring daemons, and setup utilities,\nsee [docs/commands.md](/sudheerdvn/lanegate/blob/main/docs/commands.md). `lanegate --help-all`\n\n(or `lgt --help-all`\n\n/\n`lane --help-all`\n\n) prints the complete flat command list.\n\n`.lanegate.yml`\n\nin your repo root, with walk-up discovery so it works from any subdirectory. Covers the delivery profile (`profile: strict`\n\n— enforced review independence), executor routing (`claude`\n\n, `codex`\n\n, `aider`\n\n, `ollama`\n\n, multi-executor `executor_steps`\n\n, dispatch budget caps), `safeguards`\n\n(pre/post-merge test gates, including the automatic re-verification against the real merged `main`\n\n), UI-ticket visual verification, and deployment `environments`\n\n. The Quick Start above shows a minimal `safeguards`\n\nblock to get going.\n\nSee [docs/config-reference.md](/sudheerdvn/lanegate/blob/main/docs/config-reference.md) for every supported key, defaults, and a full annotated example, and [docs/executor-capabilities.md](/sudheerdvn/lanegate/blob/main/docs/executor-capabilities.md) for the capability matrix across executors (local-model setup, headless flags, sandbox status).\n\nThe `touches`\n\nlist in each ticket is a pessimistic file-level lock scoped to a single git\ncheckout on a single machine: LaneGate holds the lock from `in_progress`\n\nthrough `in_review`\n\n,\nreleasing only at `merged`\n\n, which reduces edit collisions when multiple agents work in\nparallel. It is not semantic dependency analysis — two touch-disjoint tickets can still break\neach other through a shared API — so treat it as a coordination boundary, not a correctness\nproof. See [docs/architecture.md § Touches Lock Invariants](/sudheerdvn/lanegate/blob/main/docs/architecture.md#6-touches-lock-invariants)\nfor the full model, including lockfile-pairing guidance per ecosystem and the concurrency\nbugs fixed versus the original orchestrator.\n\n```\npython3 -m pytest tests/ -q\n```\n\nSee [CONTRIBUTING.md](/sudheerdvn/lanegate/blob/main/CONTRIBUTING.md#dev-setup) for the full test suite breakdown and the\nrelease-artifact smoke gate.\n\nMCP is built in — `lanegate mcp`\n\nstarts a stdio server exposing `board()`\n\n, `next_ticket()`\n\n,\n`start()`\n\n, `run()`\n\n, `merge()`\n\n, and the rest of the lifecycle as native tools for any\nMCP-compatible agent, no shell commands required. See\n[docs/commands.md § MCP server](/sudheerdvn/lanegate/blob/main/docs/commands.md#mcp-server) for client config and the full\ntool list, and [ docs/agent-tools.md](/sudheerdvn/lanegate/blob/main/docs/agent-tools.md) for supported agent surfaces and\ncontinuation guarantees.\n\nLaneGate's loopback Python API (`lanegate api`\n\n) is built and running today, serving board, ticket, diff, and run state as JSON/SSE. The first local UI is still planned as a small add-on launched with `lanegate ui`\n\n: a bundled TypeScript frontend over that API for board scanning, ticket detail, blocked/review triage, diffs, run logs, and read-only settings preview. The CLI remains the complete fallback for advanced or custom workflows. The UI is not a SaaS service and does not move project state out of your checkout.\n\nV1 has shipped. Next is the housekeeping wave gating the public repo (Python mypy, a duplicate-drift sweep, an A/B retest — the Go TUI module has no equivalent type-check gate yet), plus coordination-honesty work like AST-based scope hints, executor conformance tests, and stronger sandboxing. See [ROADMAP.md](/sudheerdvn/lanegate/blob/main/ROADMAP.md) for the current, maintained list — this section intentionally doesn't duplicate it.\n\n`docs/commands.md`\n\n— the full command reference: planning/reporting, the ticket lifecycle, deployment, feature flags, MCP, the local API/UI, the TUI, monitoring daemons, and setup utilities`docs/lifecycle.md`\n\n— the ticket state machine: every status, transition gates, failure edges, the auto-fix review loop, and where rebase does and doesn't happen`docs/demo-walkthrough.md`\n\n— end-to-end walkthrough: idea → analyze → parallel worktrees → review → merge, using a toy calculator project; includes a dry-run path for users without an executor configured`docs/troubleshooting.md`\n\n— FAQ and debug steps: executor hangs, stuck tickets, worktree cleanup, lock files, MCP setup, and more`SECURITY.md`\n\n— security policy, reporting vulnerabilities, and what LaneGate does and does not do`docs/security-model.md`\n\n— full threat model, trust boundaries, executor permission matrix, MCP trust model, V1 limitations, and safe usage recommendations`docs/architecture.md`\n\n— built architecture, module map, and design invariants`docs/config-reference.md`\n\n— supported`.lanegate.yml`\n\nkeys and defaults`docs/executor-capabilities.md`\n\n— capability matrix comparing Claude, Codex, Aider, and Ollama across headless support, prompt transport, local model support, auto-commit behavior, and sandbox status`docs/v2-interface-boundaries.md`\n\n— V1.5 layer boundaries (Python core / local API / UI add-on / optional runner), the`lanegate api`\n\nendpoint contract and what's built vs. still design-only, and the Go TUI spike result`.lanegate.yml.example`\n\n— annotated example configuration\n\nSee [CONTRIBUTING.md](/sudheerdvn/lanegate/blob/main/CONTRIBUTING.md) — dev setup, testing, and the DCO sign-off (`git commit -s`\n\n) required on every commit.", "url": "https://wpnews.pro/news/lanegate-git-native-worktree-orchestrator-for-ai-agents", "canonical_source": "https://github.com/sudheerdvn/lanegate", "published_at": "2026-08-29 05:36:23+00:00", "updated_at": "2026-08-29 05:48:06.968703+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-tools"], "entities": ["LaneGate", "Claude", "Codex", "Ollama", "aider"], "alternates": {"html": "https://wpnews.pro/news/lanegate-git-native-worktree-orchestrator-for-ai-agents", "markdown": "https://wpnews.pro/news/lanegate-git-native-worktree-orchestrator-for-ai-agents.md", "text": "https://wpnews.pro/news/lanegate-git-native-worktree-orchestrator-for-ai-agents.txt", "jsonld": "https://wpnews.pro/news/lanegate-git-native-worktree-orchestrator-for-ai-agents.jsonld"}}