Lody

A shared workspace for the coding agents a team already runs. A machine joins by starting a daemon from the command line, which opens a sign-in link and then stays available; the machine remains private until its owner shares it. Work is dispatched as a session from desktop, phone, web or terminal, and each session hands the conversation to an agent over the Agent Client Protocol, so Claude Code, Codex, Kimi, OpenCode or another compatible agent keeps the subscription, login, model and permission mode it was configured with. Sessions can be given their own git worktrees to work in parallel or forked into a second conversation, and inspected through per-turn or whole-session diffs with line-level comments and pull-request status next to the conversation. Agents are also given tools to create, read, message and cancel other sessions, which lets one conversation act as the coordinator of several; a running web application can be opened inside a session so element-level annotations can be sent back, and permission requests can be approved from a phone notification.

Who built itThe repository belongs to the LodyAI organisation rather than to a person, and the commit record reads like a team with automation in front of it. Of 1,201 commits, 296 are attributed to lodystage[bot], 274 to zxch3n, 262 to Leeeon233 and 223 to wibus-wee; 40 further accounts follow them, and the contributor list holds 44. The repository guidelines single those three logins out as the ones to count as the Lody team and treat everything else as community.

1. 01

   A public history that begins with a seeding commit

   The repository was created on 2026-08-07, and its oldest commit — dated twenty minutes later, 02:29 UTC the same day — is chore: prepare public source history [risk:high]: the published source history was prepared rather than accumulated. From there it ran for just under eight weeks and 1,201 commits, 437 of them in August and 764 in September, ending on 2026-09-30 with the commit that moved the desktop runtime to Electron 43. It is Apache-2.0 and 115,592 KB, and at the time of the report had 1,158 stars, 133 forks, 4 watchers and 146 open issues. Against that volume sits an unusually thin release surface: four tags — v0.88.0, v0.93.3, v0.100.0 and v0.102.0 — and only three GitHub releases, the last on 2026-09-30. What fills the gap is a changelog, apps/cli/CHANGELOG.md at 392,802 bytes and the desktop one at 115,024. The README sets out the mechanism and its limits in one paragraph: pushing a stable tag creates a draft pull request that synchronises every application version, followed by a release with generated notes, and no installers or auto-update files are built or uploaded, and the original tag is never moved. A note in the record directory is called changelog-only-releases.

2. 02

   Who commits, and the trailer that names the model

   A bot is the largest single committer — lodystage[bot] with 296 of the 1,201 commits — and the three named maintainers follow at 274, 262 and 223, with 40 other accounts behind them. The co-author trailers are the part worth reading: 470 of them, of which 136 name a Claude model. The largest single group is Claude Opus 5.5 (1M context) at 50, then Claude Opus 5 (1M context) at 39, Claude Opus 5 at 16, Claude Opus 5.5 at 14, Claude Fable 5 at 10, Claude Fable 5.1 at 5, and one line each for Claude Sonnet 5.5 and for Claude alone. The second agent identity in the history is Cursor, twelve trailers in two spellings — nine Cursor and three Cursor Agent. After those come Devin on 10, Amp on 5 and copilot-swe-agent[bot] on 3. The remainder credit people: Zixuan Chen on 106, Leeeon233 on 56, Leon Zhao on 50, an account called Lody Dev on 35, and a Test User on 22. The trailers are not the only convention: the repository guidelines require that artificial-intelligence commits end with a Model: <runtime-model-id> line, and the pull request that prepared the 0.103.0 changelog shows three commits carrying Model: gpt-6.

3. 03

   Three kinds of document, and the rule that keeps them apart

   The project draws a line and then obeys it: specs express intent, docs explain implementation, notes record decisions, each in its own tree. specs/ holds 162 files in 595 KB and almost every one has a Chinese twin — session-files.md at 28,420 bytes beside 25,131, ui-primitives.md at 30,289, session-sharing.md at 15,365, session-history-writes.md at 15,051. .agents/notes/ is larger still, 846 files and 4.2 MB, and it behaves like a state machine rather than an archive: implemented/ splits into architecture, bug-fix, feature, process, simplification and testing, with proposed/ and rejected/ beside it and a dated archived/ underneath, and the file name carries its own date — 2026-09-27-conversation-scroll-engine.md is 58,940 bytes. Twenty-eight further documents sit in .agents/docs/, and a single skill directory under .claude/skills/ holds a 9,988-byte document about the synchronisation stack. The enforcing rule is one sentence: non-trivial work must add or update the owning note in the same pull request, and only mechanical or local edits are exempt. The bilingual pairing is itself a written decision — a process note from 2026-09-12 is named agent-authored-notes-ship-both-languages — and instruction files are kept under eight kilobytes per scope, each with a nine-byte CLAUDE.md beside it that is a symlink rather than a copy.

4. 04

   What a community pull request has to look like

   The contribution policy is carried by scripts: check-pr-body.mjs is 11,783 bytes, pr-policy.mjs is 18,897, and the pull-request template is 4,366. The text the template carries is blunt about forks and size: fork-based contributions must reference an issue, all policy findings share one seven-day correction period, a community pull request over 1,000 changed lines needs a maintainer assignment on the linked issue, and one over 200 with no prior issue adds what it calls a size-specific finding. Same-repository branches are exempt from opening an issue at all. On 2026-09-30 the account Jackey-Z filed six issues in one afternoon — 1170 through 1174 and 1178 — each with version, operating system and agent runtime. Dante-dan answered two of them with the mechanism rather than a promise: the reply to 1171 names the pre-provider halt path, the field promptStarted, why ordinary user turns keep their failure acknowledgement while post-start deliveries do not, and links a fixed comparison branch. Review is also partly automated: a Codex reviewer is wired to the repository and its brief tells it to report only the two highest severities, security first. The smallest thread is a feature request from Gabyran, who wanted @ to open the mention menu mid-sentence in a language written without spaces, and who called it a personal habit he dared to turn into a contribution.

5. 05

   A build whose layout is load-bearing

   A developer document explains why the command-line build looks as it does, and most of the reasons are failures already paid for. Development bundles with esbuild in about three seconds and runs built JavaScript; there is no on-demand TypeScript loader fallback, so a development start cannot run from source. The output layout has to match production exactly, because the worker pools and the workspace watcher all locate their child by file name next to the module they were imported from; running from source would leave only TypeScript siblings, and the pools would fall back to the main thread with the reason recorded as worker_missing. The build script asserts after every build that no worker-resolving module was hoisted into the shared chunk directory, which would reintroduce the same fallback. Two further choices are marked load-bearing: dependencies stay external by absolute path, because the strict package layout has no entry for its transitive dependencies; and code splitting stays on so a dynamic import remains a real lazy boundary, without which a statically imported generated manifest would break even the version flag. The version number comes from a build-time alias, because importing the package manifest by relative path once baked a stale version into the published bundle, and it gives the evidence plainly: a published lody@0.82.1 printed 0.76.0.

6. 06

   Measured rather than argued: the desktop, the poller, the frame budget

   Several pull requests carry numbers instead of adjectives. Moving the desktop runtime from Electron 39.5.1 to 43.7.6 came with the reasoning written out: 39 is out of support and force-disabled the system window-occlusion tracking; version 44 was refused because it drops the oldest supported macOS release, needs an atomic clipboard migration the project has only specified, and has an open start-up crash — so 43, which keeps the old macOS floor and the synchronous clipboard call. The next pull request is a performance measurement in its own body: with a window visible but not focused, four working marks and two spinners left the compositor drawing a frame every vertical sync — 120 Hz on that display — at 11.4 per cent renderer, 20.4 per cent graphics process and 46 per cent window server, against 2.2, 0.8 and 8.0 with every animation paused. Pausing on blur was rejected outright because the application often sits on a second display and would look frozen, so a frame budget was added that quantises every infinite animation to 30 frames per second while unfocused. The same habit shows on the daemon side: the pull-request reconciler is a compensation path for a broken hosted webhook, polls in a fast lane at 20 seconds and a slow one at 5 minutes, discovers unlinked pull requests every 20 minutes, has no turn-end hook at all, and keeps its scheduling state under the user home directory with an environment variable as the kill switch.