IM.codes: shared agent memory and supervised remote execution for coding agents
The IM for agents. Shared Agent Context & Memory, supervised execution, and cross-agent audit across AI providers.
At a glance
- What is it?
- IM.codes is a TypeScript, MIT-licensed tool that enrolls machines as Controlled Nodes for agent operation and gives coding agents a shared memory layer across providers. The README documents the mechanism and the download path, but the project's own disclaimer is the most important line in it.
- Who is it for?
- Adopt IM.codes if you already run multiple coding agents across providers and want one memory layer plus supervised machine access, and if you accept the README's own terms: no warranties, no SLA, no backward compatibility guarantees. Do not adopt it where an audit trail or uptime commitment is a requirement, because the project explicitly disclaims both.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The two problems IM.codes actually targets
The README frames the project around two distinct failures. The first is reach: when you leave your desk, the agent keeps running in a terminal, and continuing the work means SSH, tmux attach, or waiting until you are back at the laptop. The second is judgment. A single model can fall into familiar patterns, miss issues, or produce unstable answers on hard tasks, and switching providers without shared context loses the thread. Those are different problems with different fixes, and IM.codes addresses them with different subsystems: Controlled Nodes for reach, Shared Agent Context & Memory plus multi-agent discussion for judgment. The audience is narrow and specific. You need to be running coding agents from more than one provider (the README names Claude Code, Codex, Gemini CLI, GitHub Copilot, Cursor, OpenCode, OpenClaw, and Qwen), and you need either remote access to the machines those agents run on or a way to carry context between them. If you use one agent on one laptop, the machine-control half of this project is overhead you do not need.
Controlled Nodes: what gets enrolled and what stays separate
The README describes a specific architecture for machine access. Supported computers are enrolled as Controlled Nodes rather than being made into full IM.codes source servers. That distinction matters: a node is not a second server instance, it is a restricted endpoint that an authorized agent can operate. The documented capabilities are scoped commands, individual file transfer, and typed Computer Use tools for controlling desktop applications. Every node has independent credentials, and the README states that nodes remain separate from normal server and session lists. Execution access can be disabled or revoked by the node's owner. Capable Windows nodes additionally expose browser-based remote desktop, so a person can view the screen or take over from a desktop or mobile browser. The claim that one agent, or a team of agents, can operate multiple enrolled machines is the core of the design. What the README excerpt does not give is the enrollment command itself, the credential format, or the scope syntax for a command. Those are the details you would need before trusting the model, and they are not in the supplied material.
How shared memory is supposed to carry context between providers
According to the README, durable recall comes from summarized completed work. That is the mechanism: finished sessions are condensed into reusable context rather than passed through as raw transcripts. The README also separates this from the second half of the judgment story, describing Team discussion as structured cross-model review before code lands. So there are two layers with different timing. Summarized completed work accumulates after the fact and is available to later sessions across providers. Cross-model review happens before a change is accepted. The README states that this is what turns completed work into reusable context across Claude Code, Codex, Gemini CLI, and the other listed tools. What it does not state is where the summaries are stored, how a provider is authenticated to read them, or what the summarization prompt looks like. The README excerpt also cuts off mid-sentence at the point where it would explain what the project does not do, which is unfortunate, because that sentence is probably the most useful one in the document.
Getting it running: what the README actually provides
The documentation in the supplied material is thin on installation. There is no install command, no configuration snippet, and no environment variable list in the excerpt. What the README does give is the distribution path. The project is available through the App Store for iPhone, iPad, and Apple Watch, and as a web app at app.im.codes. Watch support covers session monitoring, unread counts, push notifications, and quick replies. The repository is TypeScript, licensed MIT, on the master branch, with a homepage at im.codes. The release history is informative in a different way: the most recent entries are pinned libwebrtc SDK builds for Windows x64, dated within days of each other in August 2026, plus an Android v1.1 tag. That pattern tells you the Windows remote desktop path depends on a pinned native SDK that gets refreshed frequently. If you are evaluating this for Windows nodes, the libwebrtc pin is the thing to watch, because a native dependency that moves weekly is a different maintenance proposition from a pure TypeScript package.
The disclaimer is the specification
The README states plainly that this is an actively developed personal open-source project with no warranties, no SLA, and no guarantees of stability, security, or backward compatibility. That is not boilerplate here. Combined with the feature set, it defines the risk profile. You are being asked to enroll machines that an agent can run scoped commands on, transfer files to, and control desktop applications on, under a licence that disclaims security guarantees. The README does describe real mitigations: independent per-node credentials, separation from normal server and session lists, and owner-controlled revocation or disabling of execution access. Those are the right primitives. But the README excerpt does not document the scope model in enough detail to judge how tight a scope can be made, and it does not describe what happens to a node's credentials after revocation. The honest reading is that the project gives you the controls and tells you it will not stand behind them. That is a legitimate position for a personal project and a bad fit for anything with a compliance obligation attached.
Where a plain terminal multiplexer is the better answer
The obvious alternative for the reach problem is tmux over SSH, and the difference in approach is worth stating precisely. tmux keeps a session alive on a machine you already control and gives you a terminal when you reconnect. It does not enroll the machine as an addressable node, does not expose typed Computer Use tools, and does not give an agent a scoped command interface to a fleet of computers. IM.codes is doing something categorically different: it is putting an agent-facing control plane in front of the machines. That extra layer is the reason to use it and also the reason to be careful, because every capability it adds is a capability an authorized agent has. If your actual need is to check on a running build from your phone, tmux plus an SSH client does that with no new attack surface and no native SDK dependency. If your need is to let one agent drive three Windows machines and review its work with a second model before merge, tmux does not get you there and IM.codes is aimed exactly at that case.
Maintenance cost and what the MIT licence does not cover
The licence is MIT, which is permissive and places few obligations on you as a user of the code. It also means the disclaimer in the README is doing real work: MIT provides the software as is, and the project's own text reinforces that there is no stability or backward compatibility commitment. Practically, the maintenance surface visible in the supplied material is the pinned native SDKs. The Windows libwebrtc releases land under hashed tags and were pushed days apart in August 2026, which suggests you should expect to track those pins rather than treat them as fixed. The Android v1.1 tag indicates a second client platform with its own release cadence. There is also a licensing question the README does not address: the project bundles or pins third-party SDKs, and their terms are separate from the MIT licence on the repository. If you plan to redistribute anything built on this, check the licences on the pinned SDKs yourself. This is not legal advice, and the README gives no guidance on it.
Who this fits and what to confirm before enrolling a machine
The fit is a developer or small team already running several coding agents across providers, working on machines they own, who wants context to survive a switch between Claude Code and Codex and wants to keep sessions reachable from a phone or tablet. The multi-agent discussion feature is the part that most distinguishes it from a remote terminal, because structured cross-model review before code lands is a different workflow from simply running two agents side by side. The misfit is anyone who needs an audit trail with retention guarantees, anyone operating machines they do not own, and anyone who wants a supported product with a versioning policy. Before enrolling a first node, confirm three things against the repository at master: the exact enrollment procedure and credential format, the scope syntax available for commands and file transfer, and what revocation does to an already-issued credential. The README excerpt supplied here does not answer any of those, and they are the questions that determine whether the security model matches your environment.
Editorial conclusion
Adopt IM.codes if you already run multiple coding agents across providers and want one memory layer plus supervised machine access, and if you accept the README's own terms: no warranties, no SLA, no backward compatibility guarantees. Do not adopt it where an audit trail or uptime commitment is a requirement, because the project explicitly disclaims both. Before enrolling anything, verify the current node enrollment flow and credential revocation behaviour against the repository at master, since the README excerpt does not include the enrollment commands and the release history shows platform SDK pins moving weekly.
Community notes