imcodes

IM.codes is an open-source project that calls itself "The IM for agents," i.e., an instant messaging, memory, and review layer for agents. Its core goal is to extend terminal-based coding agents to the computers that actually do the work, and to connect context and review across multiple agents and multiple people into a single thread. The project description also includes a disclaimer: this is a personal open-source project still under active development, with no warranty, no SLA, and no guarantee of stability, security, or backward compatibility; use at your own risk.

1. Controlled Nodes and AI Remote Desktop IM.codes can register supported computers as "Controlled Nodes" without turning every machine into a full IM.codes origin server. After registering multiple machines, an agent or a team of agents can directly operate these machines to get work done: execute scope-constrained commands, move individual files, and control desktop applications through typed Computer Use tools. When a human needs to view or take over, supported Windows nodes can open a remote desktop from a browser or phone to view the screen or take direct control. Each node has independent credentials, separate from the regular server/session list, and the owner can disable or revoke its execution permissions. Download links expire, but an already downloaded installer can be retained and reused to register multiple machines. Windows remote desktop supports Control and View modes, switching monitors and resolution, and allows multiple authorized viewers or controllers to collaborate; the mobile side provides touch navigation and a virtual mouse. Remote desktop automatically selects the best available connection and degrades when a direct connection is not possible; currently only supported Windows nodes provide remote desktop, while macOS and Linux controlled nodes can still use other node capabilities, with remote desktop support planned.

2. Shared Agent Context and Memory IM.codes continuously turns completed agent work into reusable memory and feeds it back into future sessions. It materializes only the final assistant.text output, excluding streaming deltas, tool calls, and intermediate noise, solving the problem of "problem→solution"-style memory rather than log accumulation. Memory is divided into personal memory (raw and processed memory always stays local; processed summaries can optionally sync to a user-level cloud pool for cross-device sharing) and enterprise shared context (teams can publish reusable memory to workspace/project scope, view, query, and see statistics in the UI; this part is still under active development and has not yet been fully production-tested). Local semantic search and server-side pgvector recall uses multilingual embeddings and can find relevant fixes across English, Chinese, Japanese, Korean, Spanish, Russian, and mixed-language repositories. Relevant past work is automatically injected into each message and at session startup, and timeline cards show the recalled content, reason, relevance score, recall count, and last-used time. The shared context UI distinguishes raw events, processed summaries, cloud memory, and enterprise memory, and provides query, preview, archive/restore, and processing configuration controls.

III. Managed MCP tools IM.codes exposes daemon-managed stdio MCP servers to supported SDK providers, giving agents a runtime-scoped tool surface for memory, inter-agent messaging, and scheduled follow-ups without raw authentication tokens or ad hoc shell commands. Memory recall tools include search_memory (searches past work, project history, decisions, preferences, defects, commits, deployments, and previously discussed context within the caller-bound memory namespace) and list_memory_summaries (retrieves recent compact summaries without a query); results include compact references and projectionId, and get_memory_sources can expand relevant hits into source snippets when the model needs exact prior instructions, defect details, commit/deployment context, or source evidence. Memory writes include save_observation (stores useful facts, decisions, or implementation notes as user-private memory candidates) and save_preference (stores stable user preferences through an explicit preference path). Agent messaging tools: send_list_targets lists sibling sessions in the current project, and send_message sends scoped messages, optional file path references, reply requests, or broadcasts through the same protected imcodes send pipeline. Scheduling tools cron_create, cron_list, cron_update, and cron_delete manage future structured sends for reminders, periodic checks, delegated reviews, or planned team follow-ups, supporting target/session/project fields as well as optional expiration and time zone data. Tool calls are bound at runtime to the current IM.codes session, project, user, and server, and agents cannot forge namespace, user, server, token, or routing fields; memory, Send, and Cron are all behind their respective feature gates and MCP switches. The shared context UI reports the MCP readiness status for each managed provider,Tool family gating status, degradation reason, update time, and the most recent daemon-redacted tool calls.

1. Supervised Execution and Automatic Review IM.codes can drive supported agent sessions round by round: a supervisor with custom instructions evaluates each completed round at idle boundaries and decides whether to automatically continue, hand back to a human, or trigger a review loop, rather than requiring user input of "continue" each round. Auto mode can be configured per session as off, supervised, or supervised_audit. After a round ends, IM.codes can classify it as complete, continue, or ask_human, and dispatch the next continuation prompt within the same session. Automation follows a fail-closed policy: on timeout, invalid output, or misconfiguration, it hands control back to the user rather than silently guessing. Under supervised_audit, completed rounds can automatically enter the review pipeline, and a rework brief is sent back to the same session before control returns. Global defaults can provide the initial supervisor backend, model, and timeout for new sessions; new sessions snapshot these values when enabled, and each session can still individually override the backend/model/timeout and review mode. Custom supervisor instructions have two layers: the global supervisor persona and session-level additions, by default concatenated as "global, blank line, session"; checking a session's Override global ignores the global value. Unlike backend/model/timeout, global values are re-read on each dispatch, so edits take effect immediately for enabled sessions.

2. OpenSpec Automatic Delivery For OpenSpec-based changes, Auto Deliver turns a change folder into an end-to-end supervised delivery run: proposal/spec review, implementation, verification, team review, automatic module scoring, rework thresholds, and a visible final handoff. It can be started with one click from an OpenSpec change in a transport-supported programming session; IM.codes resolves the owning session, locks the Team channel to prevent conflicting runs, reads tasks.md, and maintains a run projection in the UI. Optional proposal/spec review repair uses the regular Team flow (default audit>review>plan) and reads the authoritative JSON results rather than relying on chat summaries. The daemon sends a focused implementation prompt back to the same session, handling only that OpenSpec change, tracking checked/unchecked tasks, and discovering safe verification command candidates from the project manifest. Each review will, for spec, tasks, implementation, tests and risk to generate structured scores, with evidence and summaries shown in the run details. The final scoring conclusion PASS, REWORK or BLOCKED determines whether the run can pass, be reworked within limits, or requires a human decision. The presets fast, standard, strict and deep can adjust the number of spec review rounds, the number of implementation review rounds, the maximum number of implementation prompts, and the time limit. It is fail-closed and human-owned: it requires human input when review output is invalid, time/prompt limits are exceeded, there is human intervention, the Team state is incompatible, or tasks are unreadable; it does not execute stage, commit or push, and the user is always the final release owner.

VI. Collaborative Coding A tab, subsession, or the entire origin server can be shared with other users. Use viewer for read-only review, or use participant to let teammates send prompts to a covered session. Shared messages carry participant labels, and access can be downgraded or revoked from the UI.

VII. Computer Use and Browser Automation Supported SDK agents can control desktop applications through typed Computer Use tools. The cross-platform desktop application path integrates Open Computer Use developed by Leo (iFurySt), under the MIT license, and the capability is credited to that project. Browser automation is an independent feature of IM.codes, built directly on the Chrome DevTools Protocol (CDP): agents can open, inspect, navigate, click, fill in and evaluate pages, returning structured text by default and optional screenshots only when requested; the managed browser exposes a loopback-only CDP endpoint, and local Python or Node scripts can attach to the same active instance without starting another browser.

VIII. Remote Terminal and Mobile Agent session terminals can be fully accessed from any browser, without SSH, VPN or port forwarding, and you can switch between raw terminal mode (native CLI experience) and a structured chat view with parsed tool calls. Mobile provides Watch support, including quick session monitoring, unread counts, push notifications and quick replies directly from the wrist, supports iPhone, iPad and Apple Watch, and also provides a web app.

IX. Applicable Scenarios and Limitations The main applicable scenarios are: needing to keep following up on coding agent sessions after leaving your workstation; needing unified memory and a unified tool surface across Claude Code, Codex, Gemini CLI, GitHub Copilot, Cursor, OpenCode, OpenClaw, Qwen and other providers; needing multi-model cross-review for complex tasks; needing to safely extend agents to multiple controlled computers; and needing to turn OpenSpec changes into a supervised automated delivery process. Limitations and risks include: the project explicitly states that it does not guarantee stability, security or backward compatibility; enterprise shared context is still under active development and has not yet been fully production-tested; remote desktop currently only supports supported Windows nodes, and remote desktop support for macOS and Linux is still planned; execution permissions on controlled nodes are controlled by the owner and can be revoked; Auto Deliver does not execute stage, commit or push, and the user is responsible for the final release. Some specific feature details, charging methods and prices, and a clear platform support list are not yet provided in the available materials.