IM.codes: shared memory and supervised execution for coding agents

The problem: agent sessions that die at the desk and context that dies with the session

Two failure modes show up once coding agents become part of daily work. The first is reach. The agent keeps running in a terminal, but leaving the desk means SSH, tmux attach or a remote desktop workaround, and the README describes exactly this: when you leave your desk, most coding-agent workflows fall apart. The second is judgment. A single model repeats its own patterns on hard tasks, and switching providers to get a second opinion loses the thread unless something carries context across the switch.

IM.codes targets both. It is a chat interface for Claude Code, Codex, Gemini CLI, OpenCode and others, reachable from a browser, an iPhone, an iPad, an Apple Watch or the hosted web app at app.im.codes. The README frames the second half as durable recall from summarized completed work plus structured cross-model review before code lands. The intended user is someone running multiple agents on their own infrastructure, not a team looking for a managed SaaS.

How IM.codes works: a Node daemon, Postgres with pgvector, and Controlled Nodes

The repository layout is the clearest description of the architecture. There is a server/ directory, a web/ frontend, a shared/ package, a native/ tree, and a src/ entry point compiled by tsc into dist/src/index.js, which package.json exposes as the imcodes binary. The daemon is ESM TypeScript, requires Node 22 or newer, and talks to Postgres. The docker-compose.yml pins pgvector/pgvector:pg18 rather than plain Postgres, which tells you the schema stores vector types; that is the substrate for the memory layer.

The compose file ships four services. postgres holds state in a named volume and has a pg_isready healthcheck. server runs ghcr.io/im4codes/imcodes:latest bound to 127.0.0.1:19138, and it only starts once Postgres reports healthy. caddy terminates TLS on 80 and 443 with a mounted Caddyfile. watchtower polls every 300 seconds and cleans up old images, scoped by the com.centurylinklabs.watchtower.scope label so it does not touch unrelated containers.

The second mechanism is Controlled Nodes. Instead of making every machine a full IM.codes server, you enroll supported computers as restricted nodes and let one agent or a team of agents operate them with scoped commands, individual file transfers and typed Computer Use tools. Capable Windows nodes also expose browser-based remote desktop, so a person can view or take over the screen from a desktop or a phone. Each node carries independent credentials, stays out of the normal server and session lists, and its owner can disable or revoke execution access.

Installing IM.codes with Docker Compose and generating the required secrets

The README points at the repository for self-hosting, and docker-compose.yml plus .env.example are the two files that define the setup. Start by copying the environment template. The required keys are DOMAIN, POSTGRES_PASSWORD and JWT_SIGNING_KEY; the comment in the file suggests generating secrets with openssl rand -hex 32.

cp .env.example .env
openssl rand -hex 32   # POSTGRES_PASSWORD
openssl rand -hex 32   # JWT_SIGNING_KEY

Edit .env so DOMAIN points at the hostname Caddy will serve, and paste the two generated values into POSTGRES_PASSWORD and JWT_SIGNING_KEY. Optional keys sit below them: DEFAULT_ADMIN_PASSWORD is auto-generated and printed in the logs on first run if you leave it unset, WEBAUTHN_RP_ID defaults to DOMAIN, and GITHUB_CLIENT_ID plus GITHUB_CLIENT_SECRET enable a Sign in with GitHub button on the login page.

docker compose up -d
docker compose logs -f server

The server container publishes 127.0.0.1:19138 only, so nothing is exposed directly; Caddy is what faces the network on 443. The first log lines from the server container are where you look for the generated admin password. Watchtower will pull a new ghcr.io/im4codes/imcodes:latest image within its 300 second poll interval, which means an upgrade is not a command you run but something that happens to the deployment.

There is also a CLI path. package.json declares an imcodes binary plus imcodes-launch and imcodes-launch-preflight, and the scripts include build, dev and start. The README does not document the CLI's flags, so treat the Docker route as the documented one.

What the project does not promise: stability, compatibility, and a moving image tag

The README carries a disclaimer that is unusually direct for a project with a polished landing page: 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. It describes a real operational constraint.

The version in package.json is 0.1.2, and the release list is dominated by pinned Windows libwebrtc SDK builds and an Android v1.1 tag. That tells you the remote-desktop and mobile surfaces are where the churn is. If your threat model requires a reviewed, versioned API contract, this is the wrong tool today.

The watchtower service makes the same point from the other direction. Because the compose file tracks the latest tag and polls every 300 seconds, a container restart can land you on a build you did not choose. For a personal deployment that is convenient. For anything with an uptime commitment, pin the image tag yourself and remove or scope the watchtower service, and accept that you are then the one reading release notes before every bump.

Controlled Nodes deserve the same scrutiny. Enrolling a machine gives an agent scoped command execution, file movement and typed Computer Use. The README says access is scoped and revocable and that nodes stay separate from normal session lists, but the README does not document rollback of an action an agent already took, and it does not describe a sandbox boundary around Computer Use. Enroll a machine you can rebuild.

How IM.codes compares with running tmux plus a browser terminal

The obvious alternative is the stack the README names as the problem: SSH into the box, tmux attach, and a browser terminal for the phone. That setup is free, has no database, and cannot leak an agent's context because there is no shared context store to leak. It also gives you nothing beyond reach. There is no summarized memory that survives a finished session, no second model reviewing the first, and no audited record of which agent ran what command on which machine.

IM.codes trades that simplicity for state. Postgres with pgvector holds the memory layer, the daemon brokers sessions across providers, and Controlled Nodes extend the same permission model from a shell to a desktop. The cost is a real deployment: a database to back up, a reverse proxy to keep current, secrets to rotate, and a moving latest tag. If all you need is to check on one agent from a phone, tmux over SSH is cheaper and has fewer ways to fail. The shared-memory and cross-provider audit features are what justify the extra machinery, and they only pay off when more than one agent or more than one provider is actually in play.

Maintenance cost, licensing and what the MIT grant does not cover

The licence is MIT, declared in package.json and present as a LICENSE file at the repository root. MIT permits commercial use, modification and redistribution provided the copyright notice and permission notice are kept. It grants no patent or trademark rights, and it carries no warranty, which lines up with the README's own disclaimer rather than contradicting it. Nothing here is legal advice; if you redistribute IM.codes inside a product, have counsel read the LICENSE file rather than this paragraph.

Maintenance is the larger line item. The last push was on 2026-09-10, so the repository is current as of that date, but the README does not document a release cadence, a deprecation policy or a migration path between versions. The self-hosted stack has four moving parts: the server image, Postgres with pgvector, Caddy, and the watchtower updater. Postgres major upgrades in particular will need a dump and restore, and the compose file pins pg18 with a named volume, so you cannot simply change the tag. Budget for reading release notes before each image bump, and keep the database volume backed up independently of the container lifecycle.

Editorial conclusion

Adopt IM.codes if you already run several coding agents across providers and want their completed work to become shared context, and if you are willing to run the daemon yourself on Node 22 with Postgres and pgvector behind a reverse proxy. Do not adopt it if you need an SLA, stable APIs or backward compatibility: the README states plainly that there are none, and the last push was on 2026-09-10. Before rolling it out, verify the Node version against the engines field, check that your Postgres image is pgvector/pgvector:pg18 because the schema depends on vector types, and read the .env.example to see which secrets you must generate.

Frequently asked questions

Official sources

1. im4codes/imcodes on GitHub
2. License: MIT
3. Project website
4. README
5. Releases