What was happening

MulmoClaude has a background feature called journal that auto-generates daily summaries from chat logs. It started taking an abnormally long time every time it ran hourly - some runs took 25 to 90 seconds. It felt like something was retrying over and over, and token usage was climbing noticeably.

Tracking it down

Digging in, I found that a large batch of sessions (625 of them) generated during the migration work (see last post) had been left unprocessed. The hourly job kept trying to process the entire backlog every single run, and kept failing to finish - so the next hour it would try the exact same backlog again. Close to an infinite loop.

Digging further, there was a deeper root cause underneath. The logic that checks whether a session has “already been processed” compares timestamps, and the Python side and the Node.js side handled milliseconds slightly differently - one truncating, the other rounding. That mismatch meant sessions that should have counted as “already processed” kept looking “unprocessed” every single time. A few attempted fixes didn’t stick, because none of them addressed the mismatch itself.

Stopgap, then the real fix

First I turned the journal feature off entirely to stop the bleeding. Then I fixed the timestamp handling so both languages treat precision the same way. After that, I confirmed daysSkipped: 0 and the hourly check dropped to 2-3 milliseconds.

I also revisited the schedule: journal is now pinned to run once a day (dailyIntervalHours: 24), and the hourly scheduler check itself stays lightweight.

What I took from this

“Always-on” turned out to mean more than just the app staying up - the quiet automation running behind it has to not break either. The most expensive thing was happening somewhere completely invisible from the front end.

To be continued.

Weighing the options

Leaving my laptop on 24/7 was ruled out on electricity and portability grounds. Connecting directly via SSH from my own machine was ruled out early too - corporate networks commonly block outbound port 22 (SSH). Instead I went with HTTPS over a domain, fronted by an authentication gate (Cloudflare Access). Login is via Google account, plus the app’s own shared secret (MULMOCLAUDE_AUTH_TOKEN) as a second layer.

I went back and forth with Sakura Cloud, but chose AWS Lightsail for the lower latency from its Singapore region. Started on the $7/mo bundle (1GB RAM, 2 vCPUs, 40GB SSD), planning to upgrade later if it wasn’t enough.

A silent failure: the CSRF trusted-origin gap

The migration itself went through, but sending a message from the browser just silently failed - no error, no response.

The cause: the app’s built-in CSRF guard checks the Origin header, and the new domain hadn’t been added to MULMOCLAUDE_TRUSTED_ORIGINS in .env. Adding https://mulmoclaude-taiki.com there and running systemctl restart mulmoclaude.service fixed it. If you’re self-hosting MulmoClaude and sends silently fail only from your public domain, check this first.

Chasing down “Network error calling …”

A few days later, internal MCP-bridge calls like presentForm and manageCollection started intermittently failing with “Network error calling …: fetch failed.”

My first suspicion was memory pressure. /proc/meminfo did show low MemAvailable, with swap mostly used. I installed zram-tools for compressed swap (/dev/zram0) and dropped vm.swappiness to 10 - no change. I even bumped the Lightsail plan from $7/mo (1GB) to $12/mo (2GB) just in case, and the error still reproduced 100% of the time.

The real cause turned up when I read the app’s source (server/index.ts): it’s designed to bind only to loopback - app.listen(port, "127.0.0.1", ...). The sandboxed agent reaches the host via host.docker.internal. On Docker Desktop (Mac), that resolves through a hypervisor proxy that does reach loopback. On Docker Engine (Linux), it just resolves to the real IP of the docker0 bridge (172.17.0.1 in this case) - a genuinely different interface, which a loopback-only bind will never accept a connection from. A latent bug that never surfaced on the Mac, exposed for the first time on Linux.

The fix was a single socat relay bridging the docker-bridge address to loopback:

ExecStart=/usr/bin/socat TCP-LISTEN:3001,bind=172.17.0.1,fork,reuseaddr TCP:127.0.0.1:3001

Registered as a systemd unit, and curl http://host.docker.internal:3001/ immediately started returning 200, with presentForm/manageCollection working right away. The memory/zram work wasn’t entirely wasted (headroom genuinely improved), but it was never the actual cause of this error.

Why I ended back on $12/mo (2GB)

Once the real cause was fixed, I tried downgrading back to $7/mo (1GB) to save money. Lightsail, though, doesn’t support resizing an instance down via snapshot - it meant rebuilding a 1GB instance from scratch. That rebuilt instance repeatedly hung under load (like building the Docker sandbox image), with SSH and even Lightsail’s own browser console becoming unresponsive, more than once.

I concluded 1GB can’t reliably sustain this workload (MulmoClaude itself, the Docker sandbox, and the Telegram bridge together) and settled on $12/mo (2GB) as the final plan. Stability won over saving a few dollars.

Running 24/7

A few stumbles along the way, but this server has been running around the clock ever since. I can use it anytime, from anywhere, regardless of what state my own laptop is in.

To be continued.

As a first step, here’s how it all started.

How it started

I came across “MulmoClaude” through Satoshi Nakajima’s newsletter - an open-source project that lets you self-host an AI assistant like ChatGPT or Claude on your own machine instead of as a SaaS, with conversation history and memory persisted as local files you control. I decided to set it up on my MacBook. Environment: Node.js v24.18.0, git 2.50.1, Claude Code CLI v2.1.220.

First stumble: ERR_MODULE_NOT_FOUND

There are a few install methods. I first tried the developer route: git clone-ing receptron/mulmoclaude. Running yarn install then yarn dev threw ERR_MODULE_NOT_FOUND and the server wouldn’t start. The cause: I was trying to start dev before the package workspace had actually been built. Running yarn build:packages:dev first fixed it immediately. If you hit this exact error, check that build step first.

Once it was working, I found out the officially recommended path is npx mulmoclaude@latest - no build step, no repo to manage. I switched over the same day. The port also changed, from 5173 (the git-clone/yarn dev setup) to 3001 (npx). I still run the npx version today. Had I started there, I’d have skipped the ERR_MODULE_NOT_FOUND stumble entirely.

Getting it into actual daily use

Once it was running, I made a few changes to turn it into something usable day to day. First, I wanted access when I wasn’t at my computer, so I created a bot (taiki_mulmoclaude_bot) via BotFather and wired it up following the official Telegram Bot API steps. Being able to chat with it on the go turned out to be genuinely useful.

Alongside that, everything I’d built up talking to the official Claude app (my work, where I live, my interests, day-to-day notes) got carried over as “memory” (a system that accumulates as local Markdown files) into this new setup. Picking up from that existing history, instead of starting from zero, made a real difference.

Finally, I didn’t want a broken local environment to wipe everything out, so early on I created a private GitHub repository and set up regular automated backups via git push. That habit is still going, and it later gave me the confidence to move everything to a server.

By this point, I had MulmoClaude running on my machine, reachable via Telegram, with its data backed up on GitHub. Next: moving it to an always-on cloud server.