The post list and archive page weren’t quite enough

This blog runs on Hugo + PaperMod. At first the header just had two menu items: “Posts” and “Archive.” As the post count grows, being able to browse by date or tag helps. PaperMod is a single-column theme though - there’s no concept of a sidebar built in. The content column is fixed at a max width (--nav-width: 1024px) and centered, so on a wide screen there’s blank space on either side. I figured something could go there.

First pass: just two buttons

PaperMod ships an empty hook partial called extend_footer.html - override it and you can inject arbitrary HTML at the end of every page. There’s also a convention where any CSS file dropped in assets/css/extended/*.css gets auto-concatenated into the theme’s stylesheet. Using both, I added two fixed pill buttons in the right margin: “📅 By date” linking to /archives/, and “🏷️ By tag” linking to /tags/. Just shortcuts, nothing more.

Looking at Hatena Blog, I decided to rebuild it

Plain buttons felt thin. Hatena Blog’s sidebar has an actual month-grid calendar with post days highlighted, and a tag cloud with names and counts sitting right there. I wanted that instead.

The tag cloud was easy - PaperMod’s own /tags/ page (taxonomy.html) already does exactly this, so I borrowed its logic directly:

{{ range $tagsPage.Data.Terms.Alphabetical }}
  {{ with site.GetPage (printf "/tags/%s" .Name) }}
    <a href="{{ .Permalink }}">{{ .LinkTitle }} ({{ $count }})</a>
  {{ end }}
{{ end }}

The calendar took more thought since this is a static site generator. At build time, I embed each language’s post dates, titles, and URLs as JSON inside the page ({{ $calItems | jsonify }}), then render the month grid with plain vanilla JS. No external library.

The calendar rendered nothing

I shipped it, and the tag cloud showed up fine - but the calendar area was just blank. The prev/next (‹ ›) buttons appeared; no day grid, no month title.

Checking the actual rendered HTML in devtools, I found this:

<script type="application/json" id="quick-cal-data">"[{\"date\":\"2026-08-21\",\"...\"}]"</script>

The whole array had been escaped and wrapped in quotes as a string. Feed that into JSON.parse() and you get back a single string, not an array. The .forEach() right after it obviously doesn’t exist on a string, so it threw and halted the rest of the script.

The cause was Hugo’s template engine (html/template). When you interpolate a value inside a <script> tag, Hugo automatically treats it as untrusted and escapes it as a JS string literal. jsonify returns a plain string, so Hugo wrapped the whole thing in quotes rather than trusting it as raw JS.

The fix was one line - pipe it through safeJS to tell Hugo explicitly that this JS is safe to pass through as-is:

{{ $calItems | jsonify | safeJS }}

With that, the JSON landed as a real array again, and the calendar started working.

Adding monthly jump buttons

Once the calendar worked, I wanted a way to jump straight to a given month instead of stepping through prev/next one month at a time - which gets tedious as posts accumulate. I added a list of every year-month with at least one post, newest first; clicking one jumps the calendar there in place, no page reload, reusing the same state the prev/next buttons already manage.

Where things stand

This post ends up being a record of the blog fixing itself while I was building it. Calendar, monthly buttons, and tag cloud are all in the sidebar now - next up is actually writing more posts.

To be continued.

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.