# Why I built Coding Sessions: my coding agents should not stop when my laptop sleeps *3 November 2026* ![Be lazy. Your coding agents won't be. Coding Sessions runs Claude Code, Codex and Command Code side by side on your own VPS.](https://assets.mishuk.me/writing/2026/11/254e37325cad3441-coding-sessions-be-lazy.png) For most of this year my day looked like this. I start Claude Code on a task, it works for twenty minutes, then it stops to ask me one question. I am in a meeting. My laptop is closed. The agent waits an hour for a yes. That is the problem Coding Sessions solves, and its pitch fits in one line: be lazy, your coding agents won't be. It runs Claude Code, Codex and Command Code side by side on your own VPS. It feels local. It just never sleeps. When one of them needs me, I answer it from my phone. This post is about why it exists and why it is built the way it is. The code is MIT licensed at [github.com/MishukAdhikari/coding-sessions](https://github.com/MishukAdhikari/coding-sessions). ## Agents got longer. We did not stop watching them. Two numbers explain the whole project. **Agents can work alone for longer every few months.** METR measures how long a task, timed by how long it takes a human, a frontier agent can finish on its own. That length has doubled roughly every seven months for six years, and the recent data suggests it is speeding up ([METR](https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/)). **Yet most developers still supervise them.** In Stack Overflow's 2026 look at agents at work, 63% of developers rarely or never let an agent run fully on autopilot, and 60% block agents from making unapproved changes ([Stack Overflow](https://stackoverflow.blog/2026/05/27/agents-on-a-leash-agentic-ai-remains-mostly-monitored-at-work/)). Put those together and you get my day. The work runs longer, and a human is still in the loop. So the loop has to reach the human wherever they are, and the work cannot depend on one laptop staying awake. ## What was breaking Running agents on my laptop failed in boring, repeated ways: - **The lid closes, the session dies.** Or the Wi-Fi changes, or the battery runs out. A forty-minute run is gone. - **A question waits for hours.** The agent asks something simple, and nobody sees it until I am back at my desk. - **SSH and tmux on a phone is painful.** It works, but answering a menu in a terminal on a 6-inch screen is not something I want to do in a queue. - **Every agent is its own island.** Claude, Codex and Command Code each have their own login, their own tool setup, and no way to ask each other for help. ## The decisions, and why ### The server runs the agents, not the laptop Every session lives in a terminal holder on the server, so it survives every browser and every SSH connection closing. When the web app itself restarts or updates, running agents keep going: the service is set to stop only its own process, not the agents it started. I tested this on my own server while updating it, with 14 live sessions. All 14 were still running afterwards. ### It feels local, from your laptop or your phone The web app is built for a phone first. The list shows which sessions are working, which have finished, and which are waiting on you. You open the one that is waiting, read its screen, and answer it. Each session also has a live terminal in the browser, for the moments you want the real thing. From a laptop it goes one step further. `cs term` and `cs mirror` attach your own terminal to a session on the server, natively, with your own scrollback, selection and colours. The agent runs on the VPS, but working with it feels like it is running on your machine, alongside the app and your phone. ### Hand off a branch, uncommitted work included On my laptop I am usually halfway through something. The `cs` command-line client hands that off: ```bash cs --server "fix the flaky checkout test" ``` It names the session after your branch, asks the server to prepare a workspace, uploads your uncommitted changes with rsync while skipping ignored files, and starts the agent with your prompt. When it is done, the work comes back through git. You never re-explain the context, because the agent starts from exactly where you stopped. ### MCP in three directions MCP has become the standard way to connect agents to tools. Anthropic donated it to a Linux Foundation project co-founded with Block and OpenAI, backed by Google, Microsoft and AWS, and it has more than 10,000 active public servers ([Anthropic](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation)). Coding Sessions uses it three ways, and they are deliberately separate: - **Into the app.** Claude Code, Codex or the Claude app can connect to Coding Sessions over MCP and list, launch, message, read and end sessions. Your own AI agent can drive your coding agents. - **Between sessions.** Every session gets a built-in MCP connection to its peers, with no setup or tokens. You can tell Claude to "have Codex review this and send it back", and the two agents trade messages. This channel can only send messages. It cannot launch or end sessions, so one agent cannot quietly start a fleet of others. - **Out to your tools.** Connect a remote MCP server once, sign in with OAuth or a token, and every agent the app starts shares that connection. You choose which tools each agent may use, and nothing is granted until you tick it. If your cloud provider has an MCP server, you can ask an agent to boot a server for a branch. The `cs` client itself stays on the plain HTTPS API. The API is shaped for people and scripts, and MCP for agents. Mixing them would make both worse. ### Self-hosted, because the trust question is real 81% of developers are concerned about the security and privacy of their data when using AI agents ([Stack Overflow 2025](https://thenewstack.io/23-of-devs-regularly-use-ai-agents-per-stack-overflow-survey/)). With Coding Sessions the server is yours, the agent accounts are yours, and the code lives on your disk. Sign-in uses passkeys. The Ubuntu installer runs the app under its own account with no admin rights, and stored tokens are encrypted with a key that never leaves the server. I want to be honest about the limit too. It is a tool for one trusted operator per instance. Anyone signed in can run commands as that account, and projects are not security boundaries. If you run work you do not trust, use a separate machine. ### It looks after itself Turn on automatic updates and the server checks GitHub once a day. When there is a newer release, it builds it next to the running one, switches over, and checks that it answers. If it does not start, it switches back on its own. I found a real bug this way: on Ubuntu 24.04, a fresh install refused to start because newer systemd hands credentials over in a slightly different shape. The test caught it before anyone else hit it. You can install it with the Ubuntu installer or with Docker: ```bash git clone https://github.com/MishukAdhikari/coding-sessions && cd coding-sessions echo "CS_HOSTNAME=sessions.example.com" > .env docker compose --profile https up -d ``` Docker brings automatic HTTPS through Caddy, because passkeys only work over HTTPS. ## What it does not do yet Starting a fresh session is slower than I want. On my server, preparing a workspace takes about 40 seconds, and almost all of that is copying a 1.3 GB checkout whose dependencies already exist on the disk. The next step is to share those files instead of copying them, which should bring a start down to seconds and cut each workspace to a fraction of its size. The same change lets an agent start a helper from its own folder, so delegating work feels instant. One bug from that slowness is already fixed. An agent that started a session over MCP with a prompt used to lose the prompt when the workspace took longer than a minute. Now the prompt waits and is typed the moment the agent is ready. ## What I would tell someone running agents today Do not make your laptop the place your agents live. Put them somewhere that stays awake, make sure their questions reach you wherever you are, and let them talk to each other through a standard instead of through you. The agents are getting more capable every few months. The part worth designing is how you stay in the loop without sitting in front of it. If you try Coding Sessions, I would like to hear what still makes you babysit your agents. Issues and stars on [GitHub](https://github.com/MishukAdhikari/coding-sessions) are welcome. --- *Source: https://mishuk.me/writing/why-coding-sessions*