Open Source Radar · 2026-10-23: When agents multiply, stop them stepping on each other

By Renchao Wu. Originally published on widechaos.cn.

Each day I pick five projects that are rising on GitHub this week, mostly AI agents and developer tools. I read each project's README, release notes and recent commits; I did not install them unless an entry says so. Stars and other numbers are from GitHub as of 2026-10-23.

1. feder-cr/git-ai ⭐ 966 · Go

GitHub: https://github.com/feder-cr/git-ai

In one line: a Git server designed for concurrent agent writes, with compare-and-swap landing and server-side batching.

What it is: git-ai is a Git-compatible server plus a CLI. Its design reference is Anthropic's internal system Scion, described in a public article; git-ai is an independent implementation of that described design, and the README states it is not affiliated with Anthropic. It started as a fork of GitLab's Gitaly (MIT), and the project claims compatibility with upstream RPCs; I have not tested that compatibility. The activity is a signal: the repo was created 2026-10-15 and shipped v0.1.0 the same day, then v0.2.0 on 10-18, v0.3.0 on 10-20 and v0.3.1 on 10-22; four releases in a week, five contributors.

What stands out:

• Landing without a queue. Concurrent clients can end up rebasing and retrying conflicting pushes. git-ai's UserLand rebases a change onto the current tip and lands it with one compare-and-swap; concurrent lands on the same branch are batched into a single reference update. The author's A/B run uses the same server with batching switched off (one 16-core machine, two runs, 50 agents landing 5 changes each, 20% of changes conflicting on purpose): 100-106 changes landed versus 200, attempts per landed change 26.5-28.7 versus 1.0, lands per minute 264-385 versus 1,487-1,944. The 50 changes it does not land are the planned conflicts, because that run uses no resolver.
• AI conflict resolution is only a proposal. This is the part I would copy: a conflict goes to an optional resolver, but a model's resolution lands by itself only if the verify.command you configure passes on the exact tree that would land. Otherwise the agent gets the conflict package back with the proposal attached. The server never calls a language model; the resolver is optional and provider-independent in the documented design. A passing verification command covers only the checks configured by the operator.
• History runs on the server. Blame, path history, ancestry and code search are computed server-side and memoized once per commit; clients stay online and fetch only the objects or sparse trees they need.
• The storage core is a database plus object storage. Each change is a changeset in a write-ahead log in SQLite or PostgreSQL, each reference has a compare-and-swap, packs live in object storage. The design describes server nodes as stateless caches. I have not measured scaling across nodes.
• Agents are first-class users. Per-agent tokens, an RPC allowlist and branch policies; the changeset log records the operation and the actor.

Compared with: the comparison here is not against a named competitor but against the classic write path, where each agent retries in a loop on its own client. The difference is who serialises the writes. The author's own A/B run points the same way (27 attempts versus 1), but it is the project's own benchmark, run with its own script, not a third-party reproduction.

Recent updates: v0.3.1 (10-22) fixes a real bug; UserLand read branches with Git's revision rules, so a missing refs/heads/x could resolve to a tag or a remote-tracking ref, and a land onto a branch that does not exist could be answered already_landed; every branch read now looks up the exact ref. The same release brings the CLI and SDK to Windows (the server stays Linux-only) and cuts fsyncs on the land path. v0.3.0 (10-20) completed the storage core: checkpoints, garbage collection, hydration completion handling.

Who it's for: teams where more than one agent is already editing the same repository and "someone overwrote my push" has started to hurt. The author is explicit in LIMITATIONS.md: it is not a hosting product (no web UI, issues, merge-request review or CI), not a GitLab replacement, and not a security boundary; the access policy is local configuration, whoever can edit it can change who writes where, and the shared token is an administrative credential. With four releases in a week, I would expect interface changes before 1.0.

My take: ⭐⭐⭐ the ideas are worth more than the code today; read the design docs, do not put it in production yet.

Checked: read the README, LIMITATIONS.md, all four release notes and recent commits; did not install.

2. openqodex/openqodex ⭐ 790 · TypeScript

GitHub: https://github.com/openqodex/openqodex

In one line: code review that runs inside your coding agent before you push, and the agent that wrote the code does not review it.

What it is: OpenQodex runs locally, from your terminal or your agent, and reviews "the commits you have not pushed plus everything uncommitted". The first stage has 22 model-free scanners covering secrets, code security, vulnerable dependencies, lint, GitHub Actions, Dockerfile/Terraform/Kubernetes/CloudFormation, and SQL and migrations. It keeps findings on the lines you changed. The second stage starts separate Claude Code or Codex processes as reviewers, on your own login; the project needs no account or API key of its own. Created 2026-10-02, v0.12.0 on 10-10, v0.13.0 on 10-15, four contributors.

What stands out:

• Every quote is checked by a script. Finder sessions read each part of the change and must attach a quoted line as evidence; a script checks every quote against the real code. Verifier sessions then confirm or refute each candidate and each scanner finding, with a reason for every one. Scripts also check two completeness conditions: every scanner finding was answered, and every changed line was given to a reviewer. Assignment and valid quotes do not prove that a reviewer found every bug.
• It says when it did not finish. If any stage did not run, review prints Review incomplete with what is missing and exits 2.
• The push gate knows what it does not know. The in-agent gate cannot know what a push will send, so for a plain git push it only asks whether the current work has a passing review, and for any other push command it says it cannot tell. The pre-push hook installed by init checks the exact commits a push sends. Both warn by default; they block only when review.block_on_severity is set.
• The benchmark publishes its weak numbers too. On the project's planted-bug set (dev split): with Claude Code as reviewer, issue recall 129/153 (84.3%) at $0.0870 per review; Codex 115/153 (75.2%); scanners only 32/51 (62.7%). The same README also prints the AACR-Bench row on real pull requests: semantic precision 22.8%, semantic recall 5.2%, F1 8.5%, noise rate 77.2%; marked "recall not yet ruled".
• Custom scanners need human approval. Name one in the config and openqodex trust downloads it into a quarantine folder, shows what will run, and asks yes or no; an edited entry needs a new approval.

Compared with: two useful comparison points are a review bot in CI and inline editor suggestions. OpenQodex sits between writing and pushing, with a separate reviewer, script-checked quotes, and "no answer means not reviewed". I have not run other reviewers against the same code, so this is a difference in mechanism, not a ranking of results; and the 84% recall holds only on its own planted-bug set, while the real-PR row does not yet support using it as a sole gate.

Recent updates: v0.13.0 (10-15) lets repository owners choose convention files with review.instructions_files, quotes them in review briefs, records which files were supplied and which were omitted, and binds finalize to their original content (the default reads none). The same release keeps every correction round in rounds.json beside the report, so a finding a check rejected and the next answer left out is visible. v0.12.0 (10-10) can be imported as a Node library, and preinstallScanners checks each installed scanner's version and runtime and runs a tiny real check to confirm it reports a finding.

Who it's for: people writing code with Claude Code or Codex who care about who reviewed it. Read the constraints first: Node 22+, tested on macOS and Linux only (no Windows or WSL tests), and Cursor or Cline can start a review but cannot be the reviewer; without a reviewer, review prints Full review unavailable. On privacy, the project states that the tool collects no telemetry and its scanners send no code, but the reviewer sends your change to the model service your login uses; --offline skips the four scanners that use the network, not the reviewer.

My take: ⭐⭐⭐ I would trial it as an additional review step. The reported real-PR scores do not justify relying on it as the sole gate.

Checked: read the README, docs/privacy.md, the v0.12.0 and v0.13.0 release notes and recent commits; did not install.

3. LodyAI/Lody ⭐ 1,536 · TypeScript

GitHub: https://github.com/LodyAI/Lody

In one line: a shared workspace on top of the coding agents your team already uses; connect machines, share conversations, dispatch work from a phone.

What it is: Lody trains no model and ships no agent. Each machine runs npx lody daemon start to join a workspace, and local Claude Code, Codex, Kimi, OpenCode and other ACP-compatible agents work through it; desktop, mobile, web and CLI are four doors into the same workspace. A teammate can open a conversation and see the full transcript, runtime status, files and diffs, and permission requests can be approved from a phone. Created 2026-08-07, 57 contributors in two months, four GitHub releases (v0.100.0 on 09-24, v0.104.0 on 10-08), 283 open issues.

What stands out:

• Brings your agents and machines, does not replace them. You keep the subscriptions, logins, models and permission modes already configured on your machines; machines stay private until their owner shares them with the workspace.
• Agents delegate to each other. Lody gives agents tools to create or reuse other conversations, read their status and history, send follow-up instructions, cancel running work and bring results back. One conversation can act as the coordinator and split investigation, implementation and testing across parallel conversations; child conversations stay independent but keep the relation to whoever created them, and can be referenced with an @ mention.
• Parallel work is isolated by git worktrees. Each session can have its own worktree to separate edits; this does not establish security isolation; diffs, terminals and previews sit in tabs, and PR status and CI stay next to the agent that produced the change.
• Collaborative state uses CRDTs. The Loro stack (Loro and Flock) represents and syncs collaborative state; packages/e2ee-core is an end-to-end encryption library with a signed ledger and key delivery, and the README marks it not yet wired into the product.
• Local-first is a direction, not the current state. The README says Lody is still moving toward full local-first support, and daemon start opens a sign-in link that connects the machine to a workspace, a step that goes through its online service.

Compared with: one end is the interface each agent ships with, the other is an orchestration framework that decides how agents divide work for you. Lody sits in between: it does not decide the division, it gives agents the tools to create child sessions, read status and collect results, and leaves the coordination logic in the agent's own context. The repository has connection and agent-running code in apps/cli, and the currently unintegrated encryption library in packages/e2ee-core. I did not establish whether the rest of the codebase contains other workflow mechanisms.

Recent updates: v0.104.0 (10-08) added in-session document viewers with PDF controls, stored each model's effort and Fast support in its own capability row, and made the CLI explain its personal-GitHub fallback and commit with the requester's identity (PR #1145, self-labelled risk:high). v0.100.0 (09-24) is where live read-only session sharing began (PR #539, also risk:high). The 10-23 commits fix writing to a repository after the disk is full and an EPIPE uncaught-exception storm on shutdown.

Who it's for: small teams sharing a few machines, with agents running on different boxes, who want to see what each other's agents are doing. Two preconditions: machines join its cloud workspace, and the encryption layer is not in the product yet. The issue count alone does not establish stability; I have not tested long-running sessions.

My take: ⭐⭐ the model is worth borrowing, but today's shape is a cloud workspace plus a local daemon, not pure local.

Checked: read the README, three release notes, recent commits and the repository layout; did not install.

4. browseros-ai/BrowserOS ⭐ 14,060 · TypeScript

GitHub: https://github.com/browseros-ai/BrowserOS

In one line: two products in one repository; neo is a second browser for your agents, BrowserOS is an AI browser for you.

What it is: an AGPL-3.0 Chromium fork (the README credits Felafax, Inc.) with two products side by side in one monorepo. neo turns the browser into an MCP endpoint: claw-server (Rust) exposes MCP and a JSON API, so Claude Code, Codex, Cursor, VS Code, Zed and others connect from outside and work in their own tabs while you watch a live dashboard or scrub back through the session like a video. Created 2025-05-18, 22 contributors, 288 releases; a number to read carefully, because it counts per-component channels (claw-onboard, ext-browserclaw, claw-server each release separately), not 288 big versions.

What stands out:

• Runs on 127.0.0.1 with your existing logins. The README describes importing logins, bookmarks and extensions from Chrome to reuse accounts; sessions, screenshots and history live under ~/.browserclaw/. That is a different trade-off from starting a fresh empty Chrome subprocess or running in a datacenter.
• Sessions can be replayed. Each session is saved to disk as a scrubbable video with a step-by-step action timeline, so a failure can be traced to the click that caused it.
• Parallel tabs. Fire several tasks at once, each agent in its own tab, while you keep browsing elsewhere.
• Hosted and local are being separated. The 10-22 neo onboarding release adds hosted mode for remotely driven Neo and a hosted API (/v1) to read agent sessions; 10-23 commits gate CAPTCHA solving behind hosted mode and build a private CAPTCHA-enabled image.
• The telemetry boundary is specific. Anonymous product-usage events (connect/disconnect, version, OS) are sent; the README says these telemetry events exclude URLs, page content, prompts, tool results and screenshots, and can be disabled. I have not audited traffic; this telemetry statement does not describe every model or hosted-service data flow.

Compared with: comparison points include a fresh browser in CI, a cloud browser and a browser tied to a particular agent. Login persistence and available model connections depend on each setup. BrowserOS differentiates on "your existing logins plus your existing agent": agents connect over MCP from outside, through a separate MCP service. The architecture shows that connection point; claw-server is a separate process exposing an MCP endpoint. The project also claims the same task uses fewer tokens than Claude's Chrome extension or the Codex browser; I have not measured that, and did not see a method, so it stays a project claim.

Recent updates: neo onboarding v0.0.18 (10-22) lands hosted mode and the hosted API and disables in-browser sign-in across the products; extension v0.2.41.0 (10-21) keeps sensitive fill values out of the audit ledger; claw-server v0.0.77 (10-21) adds a Docker image with noVNC and MCP, Linux arm64 release lanes, and link URLs in snapshots.

Who it's for: automation that needs real logins and should not hand accounts to a cloud browser; posting, reconciling, exporting reports. Three things to price in first: the AGPL-3.0 licence, whose obligations depend on how the software is used, modified and conveyed; a second browser profile to import logins into; and CAPTCHA handling moving toward the hosted side, so check the local/hosted feature boundary for the release you choose.

My take: ⭐⭐ account reuse and replayable sessions are useful features to inspect. The recent hosted additions make release-specific deployment boundaries worth checking. I have not measured a general shift away from local use.

Checked: read the README, the release notes of three components, the 10-23 commits and the licence; did not install.

5. labring/FastGPT ⭐ 29,893 · TypeScript

GitHub: https://github.com/labring/FastGPT

In one line: a RAG knowledge-base and visual-workflow agent platform, self-hosted with Docker, with features for maintaining knowledge bases after ingestion.

What it is: FastGPT breaks "turn documents into a Q&A app" into four layers: the knowledge base (reusable collections, chunk-level editing, QA splitting, many file formats plus URL/CSV import), retrieval (hybrid search and reranking, API knowledge bases), orchestration (chat and plugin workflows, agent-skill orchestration, two-way MCP) and operations (no-login share pages, iframe embedding, annotated conversation logs, app logs). Created 2023-02-23, the original roundup recorded 199 contributors and 146 open issues. The live GitHub page later showed 215 contributors and 113 open issues, with 33 open pull requests listed separately. Those counts depend on the measurement and time of reading. Six releases were covered over about two months.

What stands out:

• Data is persisted before indexing, with three visible states. v4.17.2 makes parsing, image import and backup import write a visible data row as soon as parsing finishes (all bound to one dataId), and the vectors are written back to that same row when training completes. A new parsed → indexing → indexed flow keeps not-yet-indexed data out of retrieval, read-only in the UI and protected from edits or deletes on the server, while failed data can be edited or deleted directly. This addresses the old problem of a long training cycle with nothing to look at and orphaned rows after an interruption.
• Upgrades are treated as a first-class feature. The release notes reviewed here include three sections: upgrade guide, image tags, and manual migration scripts. Registered migrations then run automatically with lease-based exclusion across nodes and heartbeat detection. v4.17.2 ships two migrations and states their order dependency.
• v4.17.0 is a breaking upgrade. Deploying AI Proxy and setting AIPROXY_API_ENDPOINT and AIPROXY_API_TOKEN becomes mandatory; OPENAI_BASE_URL and CHAT_API_KEY are removed and no longer take effect, and a missing config fails startup validation. The same release adds CSRF_ENABLED and a fallback for hosts whose kernel lacks seccomp (with an explicit note that system-call isolation is reduced).
• Search can be scoped to a directory. Searching inside a folder limits the range to that path and its subtree, using in-memory bucketing and level-order traversal, with guards against cycles and over-deep or over-wide trees.

Compared with: one end is a pure RAG framework or library (assemble the retrieval chain yourself; flexible, but you write code), the other is a closed SaaS knowledge base. FastGPT's position is to turn knowledge-base operations into UI and migration scripts: three-state indexing, chunk-level edits, training progress broken down by processing mode, registered upgrade scripts with concurrency protection. These mechanisms give an operator explicit states and upgrade steps to inspect. I have not compared their behavior against other frameworks on the same workload.

Recent updates: v4.17.2 (10-09) is the persisted-before-indexing work above, plus a one-to-many fix for QA splitting (the source row is reused as the first split, other leaves become new pre-persisted rows, and queueing, writing and cleanup happen in one transaction) and model switching or synonym rebuilding now triggering only on already-indexed data. v4.17.1 (09-30) adds resource-permission snapshots to app releases and folds the commercial admin UI into the main app, dropping the old paths.

Who it's for: anyone turning a frequently changing document set into Q&A where answers must cite specific clauses, and who must self-host. Look at the licence separately: the FastGPT Open Source License describes Apache-2.0 with additional use and contribution conditions. Two relevant use restrictions are that you may not run a multi-tenant SaaS similar to FastGPT without written permission, and you may not remove or modify the console's logo or copyright. These are additional restrictions, so the Apache label alone is not enough to decide whether a particular deployment is permitted; read the full licence for the intended use. It is also a heavy platform: I have not measured operating costs or established that an API-based setup is cheaper for a particular use case.

My take: ⭐⭐⭐ the explicit upgrade and migration notes are useful. I would assess the deployment burden before adopting the whole platform.

Checked: read the README, the LICENSE text, release notes from v4.17.0 to v4.17.2 and recent commits; did not deploy.

At a glance

Project	What it is	Most distinctive	Who it's for	Worth a look
git-ai	Git server for agents	CAS-batched landing; an AI resolution only counts if a verify command passes	Teams with agents editing one repo	⭐⭐⭐
openqodex	Code review inside the agent	Script-checked quotes and a verifier that must answer every finding	People coding with Claude Code or Codex	⭐⭐⭐
Lody	Shared agent workspace	Agents create child sessions; coordination stays in their context	Small teams sharing agents across machines	⭐⭐
BrowserOS	Browser for agents	Real logins plus replayable sessions, driven over MCP	Automation that needs logins and a visible trail	⭐⭐
FastGPT	RAG and orchestration platform	Persist-then-index with three states; registered upgrade migrations	Self-hosted Q&A over changing documents	⭐⭐⭐

This week's notes

• Concurrent writes, work ownership and independent review need separate controls. Three projects work the same problem at different layers: git-ai handles concurrent landing on one branch (its own run lands 200 of 250 changes instead of 100), Lody handles how multiple sessions divide work, openqodex handles the fact that the writer should not be the reviewer. These examples expose different coordination boundaries; they do not establish an industry-wide trend.

• These projects record different parts of an audit trail. git-ai records the actor on every reference update in its changeset log; openqodex keeps each correction round in rounds.json and calls a review incomplete when a finding went unanswered; BrowserOS keeps sensitive fill values out of its audit ledger. Their records cover different events. A structured record helps inspection, but does not by itself prove a correct or complete outcome.

• This batch of projects writes down what it does not do. git-ai puts "not a hosting product, not a GitLab replacement, not a security boundary" at the top of LIMITATIONS.md; openqodex prints an 8.5% semantic F1 on a real-PR benchmark and marks the recall "not yet ruled"; FastGPT puts its multi-tenant and logo conditions on the first screen of the licence. Those boundaries help evaluate fit; disclosure alone does not establish production maturity.

• Local operation needs a feature-by-feature check. Lody says plainly that it is still moving toward full local-first and that its encryption library is not in the product yet; BrowserOS has spent the last two days drawing hosted mode, a hosted API and CAPTCHA solving onto the hosted side. When a project says local-first, ask what still works with the network off.