DEV Community: kohei_wada

Spinning a Globe in the Terminal — Watching Planes, Earthquakes, and the ISS with My Own ttymap

kohei_wada — Mon, 02 Nov 2026 15:36:56 +0000

I put a globe in the terminal. Type ttymap and a world map gets drawn in braille characters that you move around with hjkl. That alone is just an old-school terminal map viewer — but on top of it this thing can show you the planes flying over your house at this very moment, scatter the last 24 hours of earthquakes in color, or track the ISS passing overhead. All inside the terminal, in 256-color braille.

The demo videos and screenshots are collected in the repo's README: https://github.com/Kohei-Wada/ttymap

What is this

The map core is straightforward. Decode Mapbox Vector Tiles, project with Mercator, bake it into Unicode Braille with 2×4 sub-pixels per cell, and lay ANSI 256-color on top. Features are spatially indexed with an R-tree. The mapscii-style "a map in your terminal" part is this one layer, and pulled out on its own it's already a respectable viewer.

The controls are vim-flavored. hjkl to pan, b/w for fast pan, C-u/C-d for half-screen pan, a/z to zoom, gg for the whole world, 0 to reset. Mouse drag and scroll work too. : for the command palette, / for Nominatim location search. Press ? and you get a live cheatsheet generated from the active keymap plus the plugins' palette entries.

Up to here it's the "a map viewer that runs in the terminal" story. It gets interesting with the plugins that sit on top.

Showing it off with plugins

Almost every ttymap feature is a plugin, and 18 of them ship with the runtime. The answer to "what is ttymap actually for" turns out to be this list. Here are the fun ones, grouped by purpose.

Watching the planet

aircraft — pulls markers for the planes currently in the air from OpenSky's public ADS-B feed. The sidebar lists altitude and speed; Enter centers the map on a given aircraft. Looking at the sky over my own house, there are more of them than you'd think.
quake — scatters USGS magnitude-2.5+ earthquakes from the past 24 hours as colored markers. A list appears in the sidebar, and it auto-jumps to the highest-magnitude epicenter.
satellite — tracks several objects at once like the ISS and Hubble. It fetches TLEs from CelesTrak and runs the orbit propagation (SGP4) in Lua.
wiki — Wikipedia geosearch. Shows nearby articles as markers and a side panel; Enter opens an extract paragraph.

Playing

geo_quiz — "find this city before time runs out." A target pops up and you have about 30 seconds to get the map center as close as possible. Submit with Enter and the camera flies to a view that frames both your guess and the real city with ◎ markers and a connecting line. The score is cumulative km error (golf-style, lower is better). Easy mode shows the country, hard mode doesn't.
travel — curated tours of Japan and Italy ship out of the box, with a choreographed pre-overview → per-city loop → post-overview tour. It's driven by ttymap.director, described below.
autospin — the camera drifts eastward at a constant rate and loops at the antimeridian. The "this is a globe" demo. Pan by hand and it stops.
antipode — from the palette, fly to the exact opposite point on the sphere. "Where's the other side of the Earth from where I am right now?"
here — IP-geolocates your current position and flies the camera home.

Networks on the map

traceroute — hit r, type a hostname, and as traceroute(8) resolves each next hop, the route's polyline grows across the map hop by hop. The sidebar lists the hops (Enter flies to that router), there's a per-hop color gradient, and consecutive * runs are collapsed in the panel. You can watch with your eyes where in the world your packets travel.
ping_simulation — a growing animation of cities pinging each other. A reference implementation for animated polyline overlays.

Each plugin is a single *.lua (or a directory with init.lua) under runtime/lua/plugin/, readable as a tutorial for writing your own.

Not just a viewer

This is the part that pushes ttymap from "interactive viewer" up to "programmable globe."

First, config is Lua. You write it in ~/.config/ttymap/init.lua. Unlike TOML, you can decide values with conditionals or computation — and that quietly pays off.

Then, scriptable scenes. There's ttymap.animation.fly_to (frame-based pan/zoom) and ttymap.director (a coroutine scheduler with fly / wait / tween). A plugin can choreograph a multi-step camera-plus-overlay sequence as procedural Lua. A tour script looks like this:

local director = require "ttymap.director"

director.run(function()
    ttymap.notify("Starting tour")
    director.fly(139.69, 35.69, 10)   -- yields until the camera arrives in Tokyo
    director.wait(120)                -- park there for ~2s at 60fps
    director.fly(-74.00, 40.71, 10)   -- glide to New York
    director.wait(120)
    director.fly(2.35, 48.86, 10)     -- on to Paris
    director.wait(120)
end)

director.fly yields until the camera arrives. So just by writing "fly to Tokyo → wait → fly to NY" procedurally, the asynchronous animations play out in order. This is what the travel plugin actually is.

User plugins go in ~/.config/ttymap/lua/plugin/. With Neovim-style stem-dedup, a same-named file overrides a bundled plugin.

Trying it

Single-user install, no root:

git clone https://github.com/Kohei-Wada/ttymap
cd ttymap
make install

This installs ~/.cargo/bin/ttymap and ~/.local/share/ttymap/ (the bundled runtime). cargo install on its own doesn't place the runtime, so it fails fast with a "did you make install?" message.

Launch:

ttymap                                       # default position
ttymap --lat 35.68 --lon 139.76 --zoom 10    # Tokyo
ttymap --style bright                        # bright theme

To "fly to my current location," call the here plugin from the : palette.

You can also take a headless snapshot — for dashboards, cron, or pipes:

ttymap snap --lat 35.68 --lon 139.76 --zoom 12               # → stdout
ttymap snap --lat 35.68 --lon 139.76 --zoom 12 -o tokyo.ans  # → file

snap emits raw xterm-256 ANSI. cat the file in a compatible terminal or pipe it to less -R.

Still WIP

It's stable enough to use daily, but it's still WIP. CLI flags, the Lua surface, and the config schema can change without notice. Under the hood it's a 7-crate workspace on Rust 2024 edition, and the build uses protox so no system protoc is needed.

The code and demo videos are here: https://github.com/Kohei-Wada/ttymap

This post was written with AI assistance and reviewed by the author.

Reproducing Copy Fail (CVE-2026-31431) in a disposable VM to feel what 732 bytes to root is like

kohei_wada — Sun, 01 Nov 2026 15:36:08 +0000

Introduction

A kernel local privilege escalation (LPE) vulnerability called "Copy Fail" (CVE-2026-31431) made the rounds. Social media and articles were full of "affected range is ≤6.19.12" and "run this command, and if it prints X you're vulnerable" — but deciding "we're vulnerable / safe" off a number and a one-liner felt wrong.

So instead of touching a production machine, I stood up a disposable VM carrying a pre-patch kernel, ran the official PoC for real, and felt with my own hands how easily root gets taken. Bottom line: a 732-byte Python one-shot took me from a non-root user to uid=0(root), no race, 100% deterministic. Along the way I verified, on the spot, that the widely circulated "check" isn't actually a patch test, and that the mitigation works.

Don't relax over a number

When a flashy CVE like Copy Fail drops, the first things to circulate are an "affected versions list" and a one-liner that says "run this, and if X shows up you're vulnerable." Handy, but there are two traps.

The affected-range number is about "pre-fix" and doesn't reflect distro backports. On Arch you have to look up your installed package's fixed version in the tracker; the upstream number alone can't tell you.
The circulating "check" isn't necessarily a patch test. The one I saw checked "is algif_aead loaded?" But that only looks at whether the module used in the attack is present — it says nothing about whether the kernel is patched. Even if it's not loaded, the attack path can come back if you can modprobe it; even if it is loaded, a patched kernel won't escalate. So this check is a different thing from whether the vulnerability exists.

Once you notice this, you want to know "what's really true for my environment" from behavior, not command output. But running a root-escalation PoC on a production machine is a bad idea. That's where a disposable VM comes in.

Isolate the pre-patch kernel in a VM and run the real thing

The plan is simple.

Don't touch the production machine (already patched).
Stand up a disposable VM carrying the pre-patch kernel.
Bring in the official PoC (primary source, not a homemade snippet) and run it there.
When done, throw the whole VM away.

The key point is "a VM, not a container." A kernel LPE like Copy Fail, on success, also punches through container isolation (the kernel is shared, so of course). If you want isolation, it has to be a VM that separates the kernel itself, or it's meaningless.

Stand up a disposable VM and apply the PoC

I prepared a cloud-init user-data that seeds an SSH key into a cloud image, and booted it directly with KVM. hostfwd forwards host port 2222 to guest port 22, so I SSH to localhost:2222.

# Boot a disposable VM carrying a pre-patch kernel (user-mode, SLIRP networking)
qemu-system-x86_64 -enable-kvm -m 2048 -smp 2 \
  -drive file=sandbox.qcow2,format=qcow2,if=virtio \
  -drive file=seed.iso,format=raw,if=virtio \
  -netdev user,id=net0,hostfwd=tcp::2222-:22 \
  -device virtio-net-pci,netdev=net0 -nographic

Since it's disposable, turning off SSH host key verification makes it easier to handle (a setting you'd never use in production).

SSHOPT="-p 2222 -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null"
ssh $SSHOPT ubuntu@localhost

Once logged into the guest, first confirm with uname -r that it's the pre-patch kernel, then obtain the official PoC from the primary source and run it. Using a PoC of clear provenance rather than copy-paste from around the web matters for being able to accurately describe what was actually reproduced.

Why "so easy"?

What unnerved me most when I ran it was its plainness.

The PoC body is a single 732-byte Python one-shot.
The trick is AF_ALG (the kernel crypto API) + splice, rewriting the page cache of /usr/bin/su 4 bytes at a time.
Run as the non-root ubuntu user, and instantly uid=0(root). It escalates with no race, 100% deterministically.

When you hear "LPE" you picture "a timing-sensitive race condition you retry a few times and rarely hit." This was different. If the conditions are met, it always goes through. Once you understand in your body that this happens "on my own machine" "if it's pre-patch," it clicks just how bad a trade it is to pin the kernel and stop updating.

Another lesson: don't aim your fear in the wrong direction. "A random make install is dangerous" predates LPE, and sudo make install doesn't even need an LPE — you're root from the start. What an LPE adds is the "damage spreads to the whole machine even from a non-root run" part; the premise that running untrusted code already puts your keys, tokens, and data at risk (root or not) doesn't change.

Confirming the mitigation actually works

After confirming escalation goes through, I tried the mitigation in the same VM: shutting down the attack path algif_aead with modprobe.

# Kill loading of the module used in the attack (works independently of the patch)
echo 'install algif_aead /bin/false' | sudo tee /etc/modprobe.d/copyfail.conf

With this in place, re-running the PoC no longer escalated. Applying the patch is the real fix, but if circumstances keep you from bumping the kernel right away, this mitigation is a fallback that works independently.

When verification is done, check that no VM process is left and clean up. Since it's disposable, you can throw away the disk image and all.

pgrep -af qemu-system   # confirm no leftovers before cleanup

Wrap-up

Don't swallow the affected-range number or a "run this" check whole. The check that was going around wasn't a patch test — it just looks at whether the attack module is loaded.
If you're worried, don't touch production; run the real PoC in a disposable VM with a pre-patch kernel and confirm by behavior. Because it's a threat that punches through containers, isolation must be a VM, not a container.
Copy Fail is 732 bytes, non-root → root, deterministic with no race. I now understand in my body that an LPE is not a "happens if you're unlucky" thing.
The real fix is the patch. If you can't bump right away, blocking algif_aead is a mitigation that works independently (verified effective in the VM).

References

This post was written with AI assistance and reviewed by the author.

Integrating 6 psychology frameworks in supernemawashi — 1 framework = 1 file parallel agents

kohei_wada — Sun, 01 Nov 2026 06:50:20 +0000

Introduction

supernemawashi's nemawashi-analyze skill stopped holding the profile as a single monolithic file and moved to 1 framework = 1 file × 1 parallel agent. Six psychology frameworks (defense mechanisms / Thomas-Kilmann / Transactional Analysis / Core Motivators / Cognitive Biases / Attachment Style) are each analyzed independently by an agent running in parallel. Here's why, and how I implemented it.

The first supernemawashi (v1.x) wrote the profile to a single markdown file (profile.md). The psychological analysis was one section inside it. That causes problems:

"I want to add one new framework" means rewriting the structure inside the monolithic file
Every re-run of analyze wipes and overwrites all the other frameworks' analyses too
The independent signals (facts) per framework get mixed, and you lose track of which judgment came from which evidence
Even if you want to parallelize, you get write contention on the one file

1 framework = 1 file × 1 agent

Decompose the profile per framework.

PROFILE_DIR/<person-name>/
├── profile.md                          ← slim index (Core Pattern + summary table only)
├── facts.jsonl                          ← facts (collect's output)
└── frameworks/
    ├── defense-mechanisms.md            ← per-framework classification + evidence + DO/DON'T
    ├── thomas-kilmann-tki.md
    ├── transactional-analysis-ta.md
    ├── core-motivators.md
    ├── cognitive-biases.md
    └── attachment-style.md

Each framework file is fully independent. Updating one doesn't touch the other five.

Make the framework registry the single source of truth

The frameworks' slug / display name / tier have one table as the source of truth:

Slug	Display name	Tier
`defense-mechanisms`	Defense Mechanisms	1
`thomas-kilmann-tki`	Conflict Mode (TKI)	1
`transactional-analysis-ta`	Ego States (TA)	1
`core-motivators`	Core Motivators	1
`cognitive-biases`	Cognitive Biases	1
`attachment-style`	Attachment Style	2

Tier 1 = analyzed by default; Tier 2 = analyzed only when signal density is sufficient (if thin, surfaced explicitly as a Data Gap). Steps to add a new framework:

Add a row to the registry table
Create frameworks/<slug>.md following the contract
Update the situation→framework priority mapping in nemawashi-reply (if needed)
Confirm the registry matches the actual files with scripts/check-frameworks.sh

Because a script detects drift between the registry and the real files, you can't break things by adding only one side.

Parallel agent dispatch

nemawashi-analyze's flow:

[1] Read the shared inputs (profile.md + facts.jsonl)
        ↓
[2] Dispatch one agent per framework in the registry, in parallel
    ┌─ agent: defense-mechanisms     ──┐
    ├─ agent: thomas-kilmann-tki     ──┤
    ├─ agent: transactional-analysis ──┤  run in parallel
    ├─ agent: core-motivators        ──┤
    ├─ agent: cognitive-biases       ──┤
    └─ agent: attachment-style       ──┘
        ↓ wait for all agents to finish
[3] Synthesis pass (synchronous)
    - Update profile.md's Framework Summary table
    - Re-derive the Core Pattern

Each agent only reads facts.jsonl and writes its own framework's frameworks/<slug>.md. It shares no state with the other agents. The synthesis pass only aggregates results — it doesn't re-analyze.

What goes in a framework file

Each frameworks/<slug>.md follows the same contract:

---
framework: Defense Mechanisms
tier: 1
output_label: Defense Mechanisms
---

# Defense Mechanisms

## Purpose
(what this framework reveals)

## Classification Guidance
(how to extract signals from facts)

## Reference Table
(mechanism / definition / observable signals / DO / DON'T)

## Rule Generation
(classification → situation-indexed rules)

## Signal Tags
(the tag format embedded in the facts jsonl)

As an example, two rows from the defense-mechanisms file's reference table:

Mechanism	Observable Signals	DO	DON'T
Rationalization	long explanations on failure / "because..." chains	validate the reason, then redirect to the future	argue directly against the justification
Passive Aggression	"I'll do it" + no movement / strategic delay	name the behavior neutrally	call it "you're being passive-aggressive"

The agent cross-references facts against this table to tag signals, decides the dominant mechanism, and generates situation-indexed rules.

Situation categories

DO/DON'T rules are indexed by situation category. nemawashi-reply looks at the category and situation and loads only the framework files it needs:

Category	Situation
When Requesting	you're asking them for something
During Conflict	disagreement / tension
When Reporting	delivering good / bad news
Routine Collaboration	day-to-day interaction

At reply time it doesn't load every framework — it narrows to the 2-3 relevant to the situation. That also cuts the context-window cost.

Gotchas

Drift between the registry and the real files: at first I synced by hand, and it always broke. I moved check-frameworks.sh into pre-commit for automatic detection.
Parallel-agent races: if each agent writes the same frameworks/<slug>.md, it obviously breaks. Strictly mapping 1 agent = 1 file avoids it.
The temptation for agents to share state: there are moments you want to "look at the other frameworks' results and adjust." Doing that regresses to the monolithic design, so it's banned — adjustment happens synchronously in the synthesis pass.
The Tier 2 threshold: attachment-style often has thin signal, so I made it Tier 2. The framework itself needs criteria to surface "I don't know" explicitly as a Data Gap.

Results

Adding a new framework is 3 steps (table + file + reply mapping), touching none of the existing frameworks
Re-running analyze doesn't break the other frameworks
Parallel dispatch shrank wallclock to roughly one framework's worth with all 6 agents running at once
Each framework file is independently readable, so you can view just the framework you want (nemawashi-show <person> --framework=defense-mechanisms, etc.)

Wrap-up

Drop the monolithic profile.md and decompose into 1 framework = 1 file × 1 agent
Make the framework registry the single source of truth, and detect drift with a check script
Parallel dispatch shortens wallclock; keep synthesis synchronous
Situation-indexed framework loading keeps the context cost down at reply time

References

This post was written with AI assistance and reviewed by the author.

I built a way for Claude Code to report progress through my home Alexa

kohei_wada — Sun, 01 Nov 2026 06:02:46 +0000

Introduction

When I hand a long-running job to Claude Code, I can't tell what's happening unless I'm watching the screen. So I built a skill that has the Echo Dot beside me read out "I'm about to do this" and "done" in Japanese. It looks simple, but the implementation hits a string of small traps: the HA SSH add-on's sshd constraints, the Amazon-side _speak APIs going silent, and /tmp being a tmpfs that wipes the script. Here's the configuration I landed on after stepping on all of them.

For what it's worth, this very post had its in-progress status ("writing the Japanese version," "verifying," "merging") read aloud from my study's Echo Dot by exactly this mechanism, while I was writing it.

When I hand Claude Code a multi-step job (edit files → wait for CI → open a PR, etc.), I lose track of progress the moment I switch to something else. Having "about to do X" and "X is done" arrive through my ears, without going to look at the CLI, lets me do other things with peace of mind.

There are several Echo Dots in the house, and HA can fire TTS. So this should have been "just call a script over ssh homeassistant and make the Echo talk." In practice it snags about three times.

The configuration that finally worked

Claude Code skill (alexa-report)
    ↓ ssh homeassistant
HA SSH add-on
    ↓ python3 /homeassistant/scripts/ha_speak.py
HA Core REST API (auth: JWT mint from .storage/auth)
    ↓ POST /api/services/notify/send_message
Alexa Devices integration
    ↓ notify.<device>_announce
Echo Dot speaks (chime + message)

Three design decisions:

Decision	Why
Use `_announce`, not `_speak`	The `Alexa.Speak` API is effectively deprecated on Amazon's side. It returns 200 OK but no sound.
Mint a JWT, don't issue a new long-lived token	You can mint a short-lived JWT with the `jwt_key` in `.storage/auth`, without growing extra tokens in the UI.
Keep the script under `/homeassistant/scripts/`	`/tmp` is tmpfs. Restart HA and the script is gone.

Implementation

1. Register the SSH key in the Advanced SSH add-on Configuration

Hand-appending to ~/.ssh/authorized_keys doesn't stick. The add-on regenerates authorized_keys from its Configuration at startup, so a manual edit is wiped on add-on restart.

HA UI → Settings → Add-ons → Advanced SSH & Web Terminal → Configuration → add your public key to authorized_keys: → Save → Restart.

2. The SSH alias and the no-SFTP trap

Client ~/.ssh/config:

Host homeassistant
  HostName 192.168.1.10
  User wada
  IdentityFile ~/.ssh/id_rsa

The HA SSH add-on's sshd has the SFTP subsystem disabled. scp on OpenSSH 9+ assumes SFTP, so it fails with subsystem request failed on channel 0. Pipe it in with ssh + cat instead:

ssh homeassistant 'cat > /homeassistant/scripts/ha_speak.py' < /path/to/ha_speak.py
# or the legacy SCP protocol
scp -O /path/to/ha_speak.py homeassistant:/homeassistant/scripts/

3. The JWT-mint script

Using the refresh_token's jwt_key (a 128-char hex) in .storage/auth, mint a short-lived JWT with HS256. PyJWT isn't installed in the SSH add-on, so build it by hand with the standard library:

import json, base64, hmac, hashlib, time, urllib.request, sys

CLIENT_NAME = "claude-code"  # key to select the refresh_token in .storage/auth
API = "http://homeassistant.local.hass.io:8123"

with open("/homeassistant/.storage/auth") as f:
    d = json.load(f)
tok = next(t for t in d["data"]["refresh_tokens"] if t.get("client_name") == CLIENT_NAME)

now = int(time.time())
b64 = lambda o: base64.urlsafe_b64encode(json.dumps(o, separators=(",", ":")).encode()).rstrip(b"=")
h = b64({"alg": "HS256", "typ": "JWT"})
p = b64({"iss": tok["id"], "iat": now, "exp": now + 300})
sig = base64.urlsafe_b64encode(
    hmac.new(tok["jwt_key"].encode(), h + b"." + p, hashlib.sha256).digest()
).rstrip(b"=")
token = (h + b"." + p + b"." + sig).decode()

def post(path, data):
    req = urllib.request.Request(
        API + path,
        data=json.dumps(data).encode(),
        headers={"Authorization": f"Bearer {token}", "Content-Type": "application/json"},
        method="POST",
    )
    return urllib.request.urlopen(req, timeout=5).status

if sys.argv[1] == "speak":
    print(post("/api/services/notify/send_message",
               {"entity_id": sys.argv[3], "message": sys.argv[2]}))

4. The Claude Code skill itself

ssh homeassistant 'sudo python3 /homeassistant/scripts/ha_speak.py speak "writing the blog draft" notify.koheisannoecho_dot_max_announce'

If you put a wrapper that calls this shell at each Before / After step inside the skill, Claude Code automatically speaks up on every long-running task.

5. The Echo entity list

Physical device	entity
Echo Dot Max (study)	`notify.koheisannoecho_dot_max_announce`
Echo Dot (living room)	`notify.echo_dot_announce`
Upstairs	`notify.er_jie_announce`
All rooms	`notify.quan_bu_nobu_wu_announce`

A Japanese group name like "全部の部屋" (all rooms) gets pinyin-slugified on the HA side (quan_bu_nobu_wu). Renaming the group changes the slug, so when adding a new one, the reliable move is to hit GET /api/services for the notify domain and check.

Gotchas

The Alexa.Speak API is silent: calling notify.<x>_speak returns 200 OK but makes no sound. You have to switch to _announce (the downside is the chime, but there's no alternative right now).
.storage/auth is root:0600: sudo python3 is required.
/tmp is tmpfs: the script disappears on HA restart. Put it under /homeassistant/scripts/.
network-online.target isn't re-evaluated on wake-from-suspend: not directly about HA, but the trap where the DNS that TTS depends on falls over is common to systemd timers in general.
JWT lifetime is 5 minutes: the premise is you mint one on every call. No need to extend it since it isn't reused.

Results

The "I have no idea what it's doing" feeling on long Claude Code sessions is gone.
I can check progress by sound alone while working on something else next to it.
Since it's a skill, it works on a new project just by calling Skill alexa-report.
I realized the "read it aloud from the Echo Dot" interface generalizes beyond Claude Code, and started repurposing it for CI-completion notifications and long-running Bash command completions too.

Wrap-up

The mechanism is just "ssh homeassistant → JWT mint → REST API → Alexa announce."
Three traps: SFTP disabled, Alexa.Speak silent, /tmp volatile.
Making it a skill lets you repurpose it outside Claude Code too.

References

This post was written with AI assistance and reviewed by the author.

Why My ESF-551 Scale Kept Disconnecting from Home Assistant: Japan's Measurement Act

kohei_wada — Sun, 01 Nov 2026 05:45:02 +0000

I connected an Etekcity ESF-551, a BLE body scale, to Home Assistant, and not a single measurement arrived. I had Claude Code chase the cause, and it ended at Article 9 of Japan's Measurement Act. Units sold in Japan have the unit switch removed because of that law.

I know nothing about firmware or law. What I did was step on the scale and decide what to have it look into next. Without AI, I couldn't have done this investigation.

Nothing comes back when I step on it

I used the HACS integration etekcity_fitness_scale_ble, which wraps etekcity_esf551_ble==0.8.4. Claude Code read the log: it showed the integration connecting, reading the HW/SW versions, writing the unit command a5220305002b0163a10000 (unit 0, kg), and getting disconnected about 0.4 seconds later. Then it reconnected and did it again. No notification ever came when I stepped on the scale, and every sensor stayed unavailable.

It happened even when the command changed nothing, kg to kg.

Skip one command and it works

I left the narrowing down to it too. Claude Code subscribed to 0000fff1 from another machine with plain bleak and left out only the unit write. No disconnect. While I stood on the scale, 22-byte notifications arrived about every 45 ms, around 80 of them.

So Claude Code wrote a local patch that passes display_unit=None and skips the write. All 14 sensors filled in. I had it write the upstream issue too, and filed it (etekcity_esf551_ble #15).

Up to here it was a story about fixing a library bug.

Only the US manual has a unit setting

I had it look for why only the Japanese version lacks a unit switch. The VeSync app has no unit setting, while the US manual has the steps.

Putting the back label next to the US spec showed this was a different market variant, not just a firmware revision. Japanese devices and IoT, again, I thought.

	US ESF-551	The unit I bought in Japan
Capacity	400 lb / 180 kg	2–150 kg
Resolution	0.05 lb / 0.02 kg	100 g
Radio approval	FCC ID 2AB22-ESF551	Giteki R 210-252428
Measurement Act	none	household "正" mark

Claude Code also pulled the Measurement Act from the e-Gov law API and read it. Article 9 forbids selling, or displaying for sale, a measuring instrument marked in non-statutory units. A scale that can show lb or st can't be sold in Japan, so manufacturers drop the unit-switch feature from the Japanese firmware. Weighing myself is neither a transaction nor a certification, so Article 8 doesn't touch the user. Only the seller is bound.

The Ministry of Economy, Trade and Industry's FY2015 test-purchase report even has a real case: a vendor who didn't know pounds and stones were prohibited was told to seal the device so it couldn't be switched.

Whether the disconnect is deliberate, I don't know

What I know is why the Japanese version has no unit switch. I can't tell whether the disconnect itself is intended, or just firmware that doesn't know the command and drops the link sloppily. Removing the feature is fine. I just suspect it was removed carelessly. I only have one unit, so I can't say that model identifier 12 in the manufacturer data marks the Japanese variant. For upstream I suggested registering identifier 12 with display_unit_settable=False so the write is skipped, and left the call to the maintainer.

An experiment that sends an unknown opcode to see how it disconnects is still undone.

Fixed the next day

The day after I filed the issue, the maintainer replied.

That's interesting to know about that Japanese regulation. That would explain it I guess, and since the option doesn't even show up in the app that pretty much confirms it I think.

Library v0.8.8 and the HA integration 0.8.3 came out the same day. I updated the integration to 0.8.3, removed my local patch, stepped on the scale, and the measurements came through. That was surprisingly fast, and I'm grateful.

Self-hosting Home Assistant is a chore. But it brings lessons like this one, from a bathroom scale all the way to a statute, and I'm glad I do it.

This post was written with AI assistance and reviewed by the author.

I Had Claude Code on the Web Dissect Its Own Sandbox

kohei_wada — Sat, 31 Oct 2026 15:34:08 +0000

I have a Claude Code on the web bot wired into my personal Slack channel. One day I idly asked it: "where are you running right now? Go inspect your own environment and tell me." What came back was a work log of the model itself digging through ps and /proc to reconstruct the ground under its own feet. So I spent two days playing with it: first having it dissect the environment from the inside, then the next day probing that boundary with exfiltration and evasion requests.

The conclusion up front: the environment is a two-layer setup — Firecracker microVM isolation plus a mandatory pass-through of all egress via a claude-internal allowlist proxy — and none of the exfiltration paths I tried got through that structure.

The Environment, Seen From Inside

There is no ip, no ifconfig, no ss. So everything has to be dug out of /proc. Here's what turned up:

OS: Ubuntu 24.04.4 LTS (Noble Numbat). whoami is root. The home dir (/root) is empty
Virtualization: inside a Firecracker microVM
NIC: eth0 = 192.0.2.2/24, GW 192.0.2.1, hostname vm, IPv4 only (no /proc/net/tcp6)

The interesting part is the NIC's address range. 192.0.2.0/24 is RFC 5737 TEST-NET-1 — a block reserved for documentation and examples that is never routed on the real internet. Instead of assigning a real IP, they deliberately hand the instance a "synthetic network that connects nowhere." The design philosophy already shows through here.

I also reconstructed the LISTEN sockets by decoding /proc/net/tcp by hand:

0.0.0.0:2024 / 0.0.0.0:2025 → PID 1 process_api (--firecracker-init). The host ↔ VM control channel, and the only thing facing outward
a few 127.0.0.1 internal ports → environment-manager (internal control API) and claude (the proxy below)

Process Tree and Data Flow

Reconstructing the layout from ps aux and the self-dissection gives this vertical spine:

you (Slack client)
      |  message / reply (stream-json)
      v
+-- Firecracker microVM ------------------------------
|
|  PID 1   process_api (--firecracker-init)
|              -> host<->VM control channel, only public listener
|
|  PID 557 environment-manager
|              -> task-run / session management (supervisor)
|
|  PID 569 claude  (conductor / the agent itself)
|      |-- spawn --> worker(bash) xN   (runs the actual commands)
|      \-- HTTPS --> agent-proxy relay (CONNECT-only, allowlist)
|                         |  allow / 403
+-------------------------+---------------------------
                          v
       allowed hosts only:  api.anthropic.com, github, npm, pypi ...
       off-allowlist hosts  -> 403

The point is the separation of execution and command. claude (PID 569) is the conductor; the actual lscpu and ps are farmed out to disposable worker(bash) processes. Incidentally claude's VSZ is a whopping 73GB, but that's V8/Node.js virtual address reservation — real RSS is ~400MB. And kill 569 is a SIGTERM to itself (this very session) — a self-destruct command.

What environment-manager Actually Is

Chasing down the environment-manager listening on 127.0.0.1 leads to /opt/env-runner/environment-manager: a ~56MB stripped Go 1.24 binary, internal name environment-runner, self-description "Environment Runner handles the lifecycle of agentic sessions." — Anthropic's session orchestrator / supervisor. It's the layer that mediates between the cloud API (the Claude Code on the web backend) and the local claude CLI.

Reconstructing its startup behavior from the binary's strings and help output, it roughly goes:

Reads a session spec JSON (~81KB) over stdin
Initializes the sandbox, MCP servers, skills, and git config in parallel
Assembles and runs claude's launch command line (model, effort, fallback, SDK URL, etc.)
Passes the auth token via file descriptor (fd 3/4) — never writing it to disk or logs, and self-masking it as <redacted> even in its logs
Measures things like spawn→ready and ttft

Its subcommands include task-run (single-session execution — PID 557 is one of these), orchestrator (a resident loop that polls for work and hands each job to task-run), and preload-claude (a warm spare). It's also the thing that installs a hook forcing every git commit to noreply@anthropic.com with a required SSH signature.

Egress Is Forced Through an Allowlist Proxy

The network is clamped down in two stages.

Firecracker VM isolation itself
A claude-internal agent-proxy relay. All outbound traffic goes through this in-process proxy, and allow / 403 is decided by a host allowlist. On top of that it's CONNECT-tunnel (HTTPS) only — a bare GET/HTTP gets bounced with 405

Here's what I actually got and didn't get when I poked at it:

Category	Example	Verdict
Auth-injected hosts	`*.googleapis.com`, `api.anthropic.com`, GitHub (push/PR OK), AWS/GCP SDK	allow
Package fetch (direct)	npm, pypi, crates.io, `proxy.golang.org`	allow
Off-allowlist hosts	arbitrary IP-check / download sites	403
Third-party PPAs (launchpad)	deadsnakes, ondrej/php	403 (`apt update` exits 100)
SSH (port 22)	`ssh <external host>`	timeout (egress is 443-centric; 22 is closed)

The pip/npm/cargo/go ecosystems go through. What doesn't is "third-party apt sources plus random sites." Even apt-get install succeeds if you stick to the core Ubuntu repos — I could install the ssh client itself. But when I tried to use that ssh to go "check external IP → check allowlist → fetch a tunnel tool," this time it wasn't the network layer but the safety classifier that caught it as "prep for egress evasion" and stopped it. The clamp isn't a single monolith.

The Next Day: Probing the Boundary

With the shape of the environment visible, the next day I flipped it around and started firing off exfiltration and evasion requests to push on the boundary. Harmless reads (uptime / ps aux / ls / various --help / local cp) all go through cleanly. What got refused was around here:

Request	Actual effect	Verdict
fork bomb	DoS	refused
`xz -9c $(find …) \	base64` wedged between two harmless lines	compress + base64-exfil an internal binary
binary disguised as `.bashrc`	the same exfil, just disguised	refused
`gdb`/`kill` to disable the egress relay	only kills the sole exit = not a bypass	refused
`go tool nm <binary>`	extracting environment-manager's symbols = reverse engineering	refused
`cat /proc/1/environ`	dumping PID 1 = `process_api`'s control secrets = credential extraction	refused

What was interesting is that renaming or restructuring the request doesn't work. Even wedging xz | base64 between two harmless command lines, it sees that "the actual effect of that line is exfiltrating an internal binary" and refuses. It draws the line on effect, not on cosmetic phrasing of the steps.

There was also a moment where merely trying to enumerate the names of environment variables got blocked as "credential discovery." That's an example of the harness's own independent safety classifier firing, separate from the model's own judgment.

Conclusion: Defense in Two Layers, Rephrasing Doesn't Help

The structure that emerged over two days of play:

The egress path is in-process and the sole exit. So killing it isn't a "bypass" — the exit just disappears
Credentials are structurally isolated (a denyRead-equivalent plus the classifier, doubled up)
Renaming / restructuring the steps doesn't work, because the model reads it by actual effect
And the harness classifier runs independently of the model's judgment, so talking one of them around still leaves the other one to stop you

The thing that finally clicked for me is the consistent line between observation and analysis. Watching behavior from the outside (eyeballing your own process with ps) — it'll cooperate. Extracting the guts of an internal binary (pulling symbols with nm) — it refuses. It'll play along with "I want to know where I'm running," but not with "let's take that mechanism apart and carry it out." You can make the resident of the sandbox introduce itself, but it won't hand you the blueprints.

For the record, the only part that's public is the sandbox execution layer (sandbox-runtime); environment-manager itself and the PaaS bits stay proprietary. Everything in this post also stays within what you can trace from the official sandboxing writeup — the story is just that if you get the resident (the model) to introduce itself, it'll answer a fair bit.

This post was written with AI assistance and reviewed by the author.

The plugin holds only WHEN, the vault holds HOW — designing a format-agnostic Claude Code plugin

kohei_wada — Fri, 30 Oct 2026 15:34:57 +0000

Introduction

My Claude Code plugin knowledge-gardener holds none of the Obsidian vault's formatting conventions (filename / frontmatter / link syntax / folder layout). Instead, it reads the vault's own README.md every time. This post is about why I did that, how it differs from existing plugins, and what properties fall out of it.

There are already several plugins that CRUD an Obsidian vault for Claude Code. Representative examples:

eugeniughelbur/obsidian-second-brain — assumes its own wiki / PARA schema
AgriciDaniel/claude-obsidian — fixes the Karpathy wiki pattern
dlutsyk/Obsidian-Zettelkasten-Claude (MCP) — forces Luhmann IDs

These hardcode the format on the plugin side. So if your vault has its own conventions — "standard markdown links (no wikilinks)," "numeric-prefix folders (01_FleetingNotes/ etc.)" — it conflicts outright. You could fork and fix it, but at that point the plugin's generality is gone.

The plugin holds WHEN, the vault holds HOW

knowledge-gardener holds only when to CRUD the vault, and follows the vault's own README for how to write.

[conventional plugin]              [knowledge-gardener]
plugin holds the format too        plugin: when to write / what to write
→ doesn't fit another vault        vault README: how to write
                                   → conventions concentrate in the vault

With this separation of concerns:

Change the conventions on the vault side and the plugin needs no edits
It can absorb format differences in someone else's vault via the README
The plugin's logic can focus on "durable-insight detection / duplicate checking / propose-then-write"

Implementation: read the README in pre-flight

I put a "Pre-flight Setup" at the top of every skill. The shared steps, abridged:

1. Resolve the vault path from the KG_VAULT environment variable
2. Read $KG_VAULT/README.md (the vault-root convention document)
3. Also read $KG_VAULT/../README.md (in case the vault is a repo subdir)
4. If a folder-scoped README exists, consult it too
5. If conventions are unclear, stop and ask — don't silently invent a default

In implementation terms, each operational skill (plant / water / connect / prune / survey / recap) handles its own CRUD action, and they share the common "Pre-flight Setup" to eliminate duplication.

Gotchas

For a vault with no README, "not running" is better. Start writing with silent defaults and you mass-produce notes that don't follow that vault's conventions. Stop-and-ask isn't a limitation — it's a spec to prevent format drift.
The vault README can live in more than one place. My vault has an Obsidian/vault/ structure, so some conventions live in Obsidian/README.md (the parent) and some in vault/README.md (the vault root). Read both, and on conflict prefer the vault root.
Folder-scoped conventions (e.g. a People folder with different frontmatter) get a separate layer that reads a folder-scoped README.

Results

The plugin runs as-is on my vault (numeric-prefix folders + standard markdown links + a custom tag namespace).
The same plugin would, in principle, run on someone else's wiki-style vault or a Luhmann-ID vault as long as they write a README.
The plugin's responsibilities are clear, so adding a new skill (garden-recap, etc.) needs no format-related decisions.

Wrap-up

It's not "the plugin holds the format" but "the vault holds the format, and the plugin reads it."
Separation of concerns: the plugin holds WHEN, the vault holds HOW.
If conventions are unclear, stop — not silently inventing a default is what prevents format drift.

References

This post was written with AI assistance and reviewed by the author.

Keeping my auto-tmux muscle memory while also touching tmux over SSH — taming the nesting with prefix+T

kohei_wada — Thu, 29 Oct 2026 15:34:04 +0000

I've gotten used to my terminal dropping me straight into tmux on open. With Ghostty it's one line.

command = tmux new-session -A -s 0

There's always one session, and it survives closing the window. Comfortable. But once you're used to that, the moment you also use tmux on an SSH host, the pain starts.

Symptom: keys don't reach the inner session

When I want to settle in and work on a remote GPU box, of course I want tmux there too — I want it to survive a disconnect. So I run ssh -t gpubox 'tmux new -A -s main', and now the local (outer) tmux and the SSH-host (inner) tmux are nested.

The problem is that both are listening for the prefix C-b. Press C-b % to split a pane in the inner session and the outer one eats it first, so it never reaches the inner. The inner tmux becomes nearly unusable.

What do other people do?

Reading around, people clearly split into two camps.

Camp 1: native terminal splits locally, tmux for remote only. If you don't use tmux locally, there's no nesting to begin with. Ghostty and WezTerm native splits need no prefix and share the clipboard. "Local splits are UI sugar, tmux is infrastructure" is the framing.

Camp 2: keep the local auto-tmux and tame the nesting. Handle it with an F12 toggle or dual prefixes.

Camp 1 appealed to me at first. But I also use Alacritty on another machine, not just Ghostty. Alacritty by design has no splits or tabs (delegating multiplexing to tmux is its official stance). So Camp 1 means only the Alacritty machine has a different workflow, and my fingers get confused.

If I want the same muscle memory on every machine, the answer flips and becomes clear. Use local tmux everywhere, and just tame the nesting. Dotfiles get written once and shipped to every machine anyway.

F12 is an awkward reach

Camp 2's canonical move is Samoshkin's F12 toggle. Press F12 and the outer tmux puts its prefix and key tables entirely "to sleep," so every key passes straight through to the inner session. Press again to return. The selling point is a prefix-free single key that round-trips.

I wrote it and tried it. It works. It works fine — but F12 is far. Reaching up to the function row for a key I toggle constantly is not kind to the fingers. I want it where my fingers already are.

The prefix is already under my fingers anyway (C-b). So I might as well move the toggle onto the prefix.

Settling on prefix+T

The final form looks like this. C-b T silences the outer session, plain T returns.

# C-b T silences the outer tmux so every key passes through to the inner (SSH) one
bind T \
  set prefix None \;\
  set key-table off \;\
  set status off \;\
  refresh-client -S
# While silenced the prefix is disabled, so the return key lives in the off table directly
bind -T off T \
  set -u prefix \;\
  set -u key-table \;\
  set -u status \;\
  refresh-client -S

One catch. The "enter" and "return" can't be the same action. After you silence the outer session, the prefix (C-b) is disabled, so the prefix+key entrance can't be pressed anymore. So the return is a bare T with no prefix, bound via bind -T off. While you're in the off key table, that's what gets caught.

The reason F12 could be a single round-trip key is that it's prefix-free, so it's still pressable while silenced. The moment you move onto the prefix, you have to split the entrance and the exit.

Showing which side you're on

At first I showed a red ● on the left of the status bar while the outer session was off. But there's a more straightforward move: just hide the outer status bar entirely (set status off).

That way, while the outer is off its bar disappears and only the inner tmux's bar is visible. It also kills the double-bar problem, and "I'm driving the inner session right now" is obvious at a glance. Return and the outer bar comes back. The config above already does this.

If your theme is catppuccin, reference theme variables like @thm_red instead of hardcoding colors, and it follows along when you change the flavor. That matters if you go the banner route instead.

Companion tricks: re-login and portability

Once the nesting is solved, two more things made it pleasant.

Kill the re-login on every pane split. The original complaint was that "splitting a pane in local tmux re-SSHes every time and it's slow." With SSH's ControlMaster reusing one connection, a new pane's ssh connects instantly.

Host gpubox
  HostName 192.168.1.50
  User myuser
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 10m

The first connection sets up the master; subsequent ones ride along with no auth and no handshake. On my machine the second connection came up in 0.03 s.

Make the config portable. My server runs NixOS, and I had default-shell /bin/bash in tmux.conf — which broke on the server. NixOS has no /bin/bash (it does have /bin/sh). Drop the hardcode for a PATH-resolved bash and it works on both Arch and NixOS.

# Stop hardcoding /bin/bash. A PATH bash works on both
set-option -g default-command 'bash -i'

Wrap-up

Local auto-tmux × remote tmux nests. The outer eats the prefix and the inner never sees it.
Pushing local splits onto native terminal panes is a popular answer, but if you also use Alacritty (which has no splits), matching every machine on tmux is easier on the fingers.
C-b T silences the outer, plain T returns. F12 works too, but if you toggle often the prefix side is within reach. The trick is that the entrance and exit live in different key tables (prefix table vs off table).
Hiding the outer status bar makes "I'm on the inner side" visible.
Killing the re-login with ControlMaster and dropping the /bin/bash hardcode for portability gives you the same experience on every machine.

The tmux.conf from this post lives in my dotfiles repository (the SSH config isn't there — it carries real hostnames).

This post was written with AI assistance and reviewed by the author.

Dropping OpenSky to Receive It Myself — Feeding RTL-SDR ADS-B into My Terminal Globe ttymap

kohei_wada — Thu, 29 Oct 2026 00:50:03 +0000

I wanted to receive it myself

Earlier I wrote about building ttymap, a globe you spin inside the terminal. A braille-character globe with planes, earthquakes, the ISS and more layered on top. The aircraft plugin that shows those planes hit OpenSky Network's public ADS-B feed. Handy, but really you're just watching the result someone else's server received and formatted.

The radio those overhead planes emit is raining down on my own room right now too. So I'd rather receive it on my own antenna and put it on my own globe. A receive-only RTL-SDR needs no radio license here. I bought a dongle and a dipole antenna.

This post is the record of what happened from plugging that dongle in to "planes I received myself" drifting across my homemade globe.

Plug it in and it's a TV tuner

Plug it into USB, look at lsusb, and you get this.

Bus 003 Device 007: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T

DVB-T. A digital terrestrial television tuner. No surprise: the RTL2832U chip inside an RTL-SDR was originally sold in bulk as a "cheap USB digital-TV tuner," and only later did someone discover that "if you make it spit out raw, pre-demodulation I/Q samples you can receive any radio = it becomes an SDR," giving it a second life.

So the moment you plug it in, the Linux kernel grabs it as a TV tuner. A driver called dvb_usb_rtl28xxu. That's the problem:

            ┌─ dvb_usb_rtl28xxu (kernel / for TV)   ← if it grabs the device, SDR can't open it
RTL2832U ───┤
            └─ librtlsdr (userspace / for SDR)       ← this is the one I want for reception

Two drivers can't grab one device at once. To use it as an SDR, you blacklist the TV driver so it doesn't claim it. Arch's rtl-sdr package, thankfully, does this out of the box in /usr/lib/modprobe.d/rtlsdr.conf.

blacklist dvb_usb_rtl28xxu
blacklist e4000
blacklist rtl2832

Check the dongle and tuner model with rtl_test.

$ rtl_test -t
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001
Found Rafael Micro R820T tuner

R820T. It reaches up to 1090MHz, so it picks up ADS-B (1090MHz) just fine. The hardware is alive.

You can catch raw frames. But they aren't coordinates

The easiest way to catch ADS-B is to just run rtl_adsb, bundled with the rtl-sdr package.

$ rtl_adsb
*8d8622ae58c906dd3078d6822f73;
*8d84b7b699088411219a359bb254;
*8d9632ae58c906dd...;
...

Lines starting with *8d are DF17 (ADS-B Extended Squitter), the payload messages carrying position and velocity. More than 30 of them in 20 seconds, across several aircraft. The dipole → R820T → librtlsdr reception chain works.

…but these aren't coordinates. They're raw Mode-S frames. Getting lat/lon out of here needs one more step: CPR (Compact Position Reporting) decoding.

Why isn't the raw lat/lon just sitting in there? An ADS-B message is only 112 bits, and packing full-precision latitude/longitude every time would eat too much bandwidth. So CPR encodes position split into two kinds, "even frames" and "odd frames." Pair an even with an odd and you can uniquely recover the position anywhere on Earth (global decoding). Alternatively, if you roughly know the receiver's position, you can recover it locally from a single frame. The latter is easier to implement. I know my receiver's (home) coordinates, so I use that one.

Writing CPR by hand is painful, so I throw it at pure-Python pyModeS. v3 has an API where you hand it one message and it returns every field as a dict; pass a rough receiver position to reference and it decodes locally.

import pyModeS as pms
r = pms.decode(msg, reference=(MY_LAT, MY_LON))
# r["latitude"], r["longitude"], r["altitude"], r["callsign"], r["crc_valid"] ...

Write a small script that just pipes rtl_adsb's output into this, run it, and coordinates start scrolling in the terminal.

21:29:39  89912B  EVA195    lat=  34.8097  lon= 136.9325  alt=37975ft
21:29:39  851826  JAL229    lat=  34.5754  lon= 136.7913  alt=27600ft
21:29:50  861F00  JAL616    lat=  34.3943  lon= 136.7036  alt=41000ft

Callsign, ICAO address, lat/lon, altitude. The same aircraft's coordinates move smoothly and consecutively (JAL616 heading south, JAL229 descending), so the decode is correct. A real plane I received on my own antenna has become coordinates.

Feeding it into ttymap — bridge a JSON server in between

Now I want this on my homemade globe, ttymap. The intake a ttymap plugin uses for data is ttymap.http:fetch(url) — basically, fetch JSON over HTTP. The earlier aircraft plugin also did http:fetch against OpenSky's REST API and plotted points with map:point(lon, lat, …).

But this rtl_adsb | pyModeS only spits text to stdout; it has no HTTP intake. The shapes don't match.

So I bridge a small thing in between. I wrote an HTTP server in Python's standard library that runs rtl_adsb as a child process, holds the aircraft state pyModeS decodes keyed by ICAO, and just serves it at 127.0.0.1:8888/aircraft.json.

rtl_adsb ──▶ serve.py (decode with pyModeS + hold aircraft state) ──HTTP /aircraft.json──▶ ttymap

The key was changing the decoder from "one frame → print one line" into "accumulate state per ICAO." Position arrives in position messages, callsign in identification messages, heading in velocity messages (velocity's track) — each comes in piecemeal from different messages, so you grow a record per aircraft and drop it once it goes unheard for a while. The JSON it serves looks like this.

{
  "aircraft": [
    {
      "icao": "861f00",
      "callsign": "JAL616",
      "lat": 34.39,
      "lon": 136.7,
      "alt": 41000,
      "heading": 182.8,
      "on_ground": false
    }
  ]
}

Writing the plugin — heading as an arrow

A ttymap user plugin goes in ~/.config/ttymap/lua/plugin/<name>.lua, and you enable it with require "plugin.<name>" in ~/.config/ttymap/init.lua. The body is almost entirely cribbed from the bundled aircraft plugin, with only the fetch target swapped for the local server.

The crux is, inside on_tick (called every frame), to fire http:fetch at a fixed interval, parse the returned JSON, and plot points. To match the earlier aircraft, I render the heading as an 8-direction arrow (↑↗→↘↓↙←↖).

local ARROWS = { "↑", "↗", "→", "↘", "↓", "↙", "←", "↖" }
local function heading_arrow(deg)
    local n = deg % 360
    return ARROWS[math.floor((n + 22.5) / 45) % 8 + 1]
end

-- inside on_tick:
for i, a in ipairs(state.aircraft) do
    map:point(a.lon, a.lat, heading_arrow(a.heading), "accent")
end

The sidebar lists callsign and altitude; select one and press Enter and the map flies to that aircraft (anim.fly_to). This card UI is just ttymap.api.card.open again — the machinery I built in the earlier post works as-is.

My own radio drifts across the globe

Start the server, call Toggle local ADS-B from ttymap's command palette, and arrows appear over my home. Each arrow tilts toward its heading, and picking a callsign flies the camera to that plane. What used to be watching someone else's server called OpenSky has turned into radio I received on the antenna I set up myself. On the very same braille globe.

What was quietly interesting was the range. Even just standing the cheap indoor dipole by the window and opening it into a V, high-altitude cruisers came through from around 100km out. It's not scattered all across the map — just a handful of nearby planes dotted on it — but seeing "how far my own antenna reaches" with my own eyes is fun.

Gotchas, collected

Plug it in and it's recognized as a DVB-T tuner. You can't open it as an SDR unless you blacklist the kernel TV driver (dvb_usb_rtl28xxu). Arch's rtl-sdr package handles it via modprobe.d.
Raw frames aren't coordinates. ADS-B position is CPR-encoded and needs an even/odd pair or a receiver-position reference. Throwing it at pyModeS is the easy path.
ttymap's intake is HTTP JSON. A decoder that only spits to stdout needs a local HTTP server bridged in between to match shapes.

What's next

Receive-only already got me this far. A fun next direction: coherent reception across multiple antennas to get the bearing (DF) of a signal, draw bearing lines on the map, and locate the source from the intersection of two stations — that kind of thing (KrakenSDR and friends). map:polyline is the same primitive I used for traceroute hops in the earlier post.

When you can feed your own tools data you received yourself, the resolution of the world goes up a notch.

This post was written with AI assistance and reviewed by the author.

A 3x Faster Local LLM That Can't Finish the Job — Two Days of MoE vs Dense on Real Tasks

kohei_wada — Tue, 27 Oct 2026 15:40:55 +0000

Introduction

I run ollama on a home RTX 5090 (32GB) and use it through opencode. My default model
had long been the dense Qwen3.6 27B, but when I tried Ornith 1.0 35B (35B/A3B),
a coding-focused MoE model, the numbers were too good to ignore — single-shot code
generation at equal-or-better quality and about 3x faster (246 tok/s vs 71 tok/s).
I swapped the default immediately.

This post is the record of that decision falling apart within two days. The
conclusion up front: the source of MoE's speed and the cause of its failures in
agent work turned out to be the same thing.

Day 1: Chosen by measurement, not benchmarks (or so I thought)

Benchmarks are mostly self-reported, so I lined the models up on my own tasks:
implementing a function from a spec (14 independently-scored cases), fixing a
planted bug, and reviewing a shell script.

Task	Ornith 35B (MoE)	Qwen3.6 27B (dense)
Implement from spec (14 cases)	14/14, 22s	14/14, 58s
Fix planted bug	correct, 24s	correct, 55s
Script review	9 findings, 19s	6 findings, 96s

For one-shot work there was nothing to argue about. On review it even beat the
dense model on finding count. "MoE for coding, settled" — that's how it looked.

Day 2, morning: cracks appear on general tasks

As the default, it also handles general tasks like looking things up. That's when
strange answers started coming back.

Asked "how many days until the next public holiday?", it did search — but then
fabricated a holiday out of nothing but the search snippets. "August 1st is a
substitute holiday for Children's Day," it said. Complete nonsense.

Adding prompt discipline (don't answer until you've read the page body, always
check the current date with a tool, do date arithmetic with shell date) corrected
the behavior — but it still misread the page and got the holiday's date wrong.
Discipline reduces it; it doesn't eliminate it.

The same question given to the dense Qwen3.6: it fetched the current date with a
tool, read the holiday-list page body, wrote and ran the day-count arithmetic in
Python, and got everything right. By this point I had a bad feeling.

Day 2, afternoon: a port experiment with a machine as the judge

To settle it, I designed an experiment: porting RFC 6902 (JSON Patch) to Rust.
The subject was chosen deliberately:

The spec and a reference implementation already exist — minimal room for the model to "judge" anything
An official conformance suite exists (language-neutral JSON, 112 cases) — completion can be decided by a machine

I split the work into phases — T0 (build the test runner), T1 (JSON Pointer),
T2 (add/remove/replace), T3 (move/copy/test) — and fixed each phase's completion
criterion as "cargo test prints total=112 pass=N fail=0".
The model's "done!" counts for nothing. Only test output judges.

Result: Ornith went 0 for 5

Across five sessions, Ornith failed to close a single phase. The failure modes are
the interesting part:

Forgot to add the dependency and reported "done" with code that didn't compile
Wrote a test runner with contradictory asserts (requiring filename to be both A and B — guaranteed panic if ever called). It also ran cargo init for a whole separate project inside tests/, unprompted
Wrote a file that cut off mid-comment at line 238 — and at the truncation point, the leaked text read "let me reconcile:", its chain of thought bleeding into the code
Built itself a correct TODO list, then abandoned the session partway through item one
Wrote calls to op_add / op_remove without ever writing the function bodies, and finished

They share one trait: every failure left behind a plausible-looking artifact and
a confident completion report. Without the rule of only trusting test output, all
five would have passed as "done."

The dense model finished every phase

Handing the same phases to Qwen3.6: slow, but it closed all of them. It wrote the
runner correctly on the first attempt, produced the 112-case tally, and eventually
reached full conformance green (pass=108 / fail=0 / skipped=4, the officially
disabled cases).

There was exactly one trick to the dense side: cut tasks down until they fit in
one session. At 71 tok/s with always-on reasoning it's slow, so putting diagnosis
and fix in the same session runs out the clock. Diagnose upstream, hand over the
established facts, and let it do only the fix — that's fast enough.

Why this happens: the speed and the failures share one cause

Ornith is not stupid — recall that it beat the dense model on the one-shot review.
It's not smaller either: at 35B total it's bigger than Qwen3.6's 27B, and it still
lost.

MoE's 3x speed comes from waking only ~3B active parameters per token. And that
economy appears to be what thins out its ability to carry state across turns —
an inference drawn from five failures, but they line up cleanly. All
five happened in "decide the next step based on what you just did"
territory — wiring up the edit you just made, working through the TODO list you
just wrote, finishing the function you just started.

So the boundary is not "coding vs general tasks." It's
"closes in one shot vs carries state." Search-then-answer works.
Search-extract-compute falls over. Generate-wire-test falls over too.

Where things landed

Default = Qwen3.6 27B (dense). Make the model that survives multi-step work the standard. The nastiest failure mode — not realizing a task is multi-step, handing it to the fast model, and getting silently wrecked — disappears with the default
Ornith demoted to a named speed lane. An opencode custom agent with "tasks that close in one or two tool calls only; if it turns out to need chaining, step aside" baked in. It keeps one-shot generation and device control
Completion judged by machines, fixed. Tests, state read-backs, tally lines with fixed case counts. In this whole experiment the number of times I trusted a model's completion report was zero — and that's the only reason it worked

Not benchmark scores, not tok/s — measuring where a model breaks, on your own
tasks, is the real work of choosing a local LLM. The 3x speed stings to give up.
But speed that doesn't finish isn't speed.

This post was written with AI assistance and reviewed by the author.

Running DiffusionGemma Locally on an RTX 5090 with vLLM: The One-Time Pioneer Cost of Bleeding-Edge Model Bleeding-Edge GPU

kohei_wada — Mon, 26 Oct 2026 15:50:28 +0000

Introduction

In the previous post I covered keeping a home RTX 5090 (Blackwell) alive 24/7 against the GSP hang. This time it's about the model that runs on top of it — a record of standing up Google's diffusion language model DiffusionGemma locally on that 5090.

Let me lead with the conclusion. It's genuinely fast — roughly ~300 tok/s by feel. But the surrounding ecosystem is still immature (Open WebUI's web search doesn't integrate, among other things), so it earned a place as an "experiment to test the speed" rather than a daily driver. So this post isn't a victory lap about landing the best local model — it's a record of the one-time pioneer cost you pay when you run a bleeding-edge model on a bleeding-edge GPU.

Why not ollama, why vLLM

DiffusionGemma isn't a normal autoregressive model. It generates via block diffusion — autoregressive between blocks, parallel diffusion within a block — and that's the source of the speed. It doesn't emit one token at a time left-to-right, so generation latency is inherently shorter.

The catch is that the serving stack gets correspondingly special.

ollama is out. It's not in the official library, and ollama doesn't expose llama.cpp's diffusion decode path. The GGUF is for llama.cpp's diffusion CLI and won't become an OpenAI-compatible server.
vLLM was the only OpenAI-compatible path. It's the only way to drop the model into Open WebUI as "just another model." Since Open WebUI is itself a multimodal hub, you don't add a new tool — you just add one more backend.

NVFP4 is the only thing that fits 32GB

The RTX 5090 has 32GB of VRAM. Trying to fit DiffusionGemma into that narrows the quantization choices hard.

bf16 is in the 96GB class; even INT8 needs 48GB. The only thing that fits in 32GB is NVFP4.
I used nvidia/diffusiongemma-26B-A4B-it-NVFP4. Its license is gated=False, so you don't even need an HF token.

The recipe that worked (raw podman)

Here's the launch command that finally came up:

podman run -d --name vllm-diffusiongemma \
  --device=nvidia.com/gpu=all --network=host \
  -v /srv/models/hf-cache:/root/.cache/huggingface \
  -e VLLM_USE_V2_MODEL_RUNNER=1 -e HF_HUB_DISABLE_XET=1 \
  docker.io/vllm/vllm-openai:gemma-x86_64-cu130 \
  nvidia/diffusiongemma-26B-A4B-it-NVFP4 \
  --host 0.0.0.0 --port 8000 --max-num-seqs 4 \
  --attention-backend TRITON_ATTN \
  --enable-auto-tool-choice --tool-call-parser gemma4 --reasoning-parser gemma4 \
  --gpu-memory-utilization 0.7

Two things to watch.

Match the image tag to the host's CUDA. CUDA 13.x → gemma-x86_64-cu130.
The architecture DiffusionGemmaForBlockDiffusion is built into the gemma image, so you don't need --trust-remote-code. It's a small thing but a real security point: you're not executing arbitrary code from the model repo — zero RCE exposure.

Cold start is ~140s (torch.compile + multimodal warmup; weights already cached). Once /v1/models and /v1/chat/completions answer, you're up.

Trap 1: the VRAM precheck kills startup instantly

My first attempt was --gpu-memory-utilization 0.9, and it died before startup.

ValueError: Free memory ... less than desired

vLLM requires util × TOTAL(32GiB) ≤ current free VRAM before it starts. But the baseline — nvidia-persistenced and friends — already takes ~4GiB, leaving only ~27GiB free. So 0.9 (asking for ~29GiB) dies at the precheck. You have to pick a value that subtracts the baseline. 0.7 (~22GiB) passed, and it still held a 256K context.

Trap 2: a container that wedges in a crash loop

When startup failed and it entered a restart loop, a container that didn't get killed cleanly got stuck in "Stopping," and podman rm -f started timing out (main thread in Z, child threads in S).

I first suspected the GPU or driver had wedged, but nvidia-smi was responding, which ruled that out. The GPU was fine; only the container side was stuck. Here's the sequence that removed it without a reboot:

systemctl stop podman-vllm-diffusiongemma   # stop the restart loop
systemctl reset-failed podman-vllm-diffusiongemma
kill -9 <pid>
podman rm -f --time 1 vllm-diffusiongemma

The trick was distinguishing "the GPU broke" from "the container wedged" by whether nvidia-smi answers.

Making it on-demand and declarative on NixOS

There's only one GPU, so it fights the big ollama models for VRAM. So I made it on-demand — dormant by default, started only when needed. Declared via oci-containers, with the exclusion enforced in systemd:

conflicts = ["ollama.service"] — starting vLLM stops ollama, freeing the VRAM.
wantedBy = lib.mkForce [] — no auto-start at boot.

It's dormant most of the time. systemctl start podman-vllm-diffusiongemma wakes it; when I'm done I stop it and start ollama to go back. Open WebUI connects with a single env line (OPENAI_API_BASE_URLS = "http://127.0.0.1:8000/v1" plus a dummy key), and while vLLM is stopped that model simply drops off the list.

Takeaways and the generalizable lesson

The speed (block diffusion) is real. But for daily use it has too many sharp edges — Open WebUI's web search doesn't work, penalty-family parameters are ignored, the default max_tokens is 256. So I decided to leave it parked as an experiment, config and all (resume is one systemctl away; image and weights are cached).

Here's the generalization I'd pull out of it:

Mature models are a one-liner; bleeding-edge ones you pioneer by hand exactly once — then declare it, and it's a one-liner forever after.

A bleeding-edge model × a new-generation GPU is the intersection where the software stack is least mature. And the nasty part is that even when the eval (can the model load at all) passes, it's the on-machine resource precheck where it first falls over. This is the class of failure you can't see on paper — it only surfaces at runtime. Which is exactly why you pioneer it once by hand, freeze the working config declaratively, and reproduce it with a single systemctl start next time. Deciding whether that one-time pioneer cost is worth paying is, I think, the whole point of this kind of experiment.

This post was written with AI assistance and reviewed by the author.

Running Blackwell (RTX 5090) Headless 24/7: The Real Boss Is the GSP Hang, and I Took It With a "Assume It Breaks" Watchdog

kohei_wada — Sun, 25 Oct 2026 15:36:14 +0000

Introduction

In the previous post I covered picking NixOS for my home AI server and doing the base install. Once the OS is in, the next step is enabling the GPU and getting to the actual goal — running local LLMs 24/7. But this is where the hardest obstacle lives: the GSP heartbeat timeout, an as-yet-unresolved hang bug.

The GPU is an RTX 5090 (Blackwell generation). Repurposing a latest-gen consumer card as a server is pioneer territory with almost no community precedent for stable operation. So this time, instead of "run it and deal with problems later," I decided to scout the landmines before stepping on them. This post is a write-up of the known issues that scouting surfaced, and the watchdog design I built assuming the hang will eventually hit.

To be honest up front: this isn't a war story of "my GPU crashed a dozen times." It's the story of scouting ahead and preparing a catch for when it breaks. The first-hand part I'm writing about is that design decision.

First, the settled facts: driver and CUDA

Let's clear the parts you can settle by just looking them up, before they bite.

The driver is `nvidia-open`, no choice

Blackwell is completely unsupported by the proprietary driver (per NVIDIA). There's no alternative, and NixOS enforces declaring open via an assertion for driver >= 560. Headless operation also wants nvidiaPersistenced — the right setting to keep the GPU awake even when headless.

hardware.nvidia = {
  open = true;               # the only option on Blackwell
  nvidiaPersistenced = true; # keeps the GPU initialized while headless
};

CUDA / inference-stack traps

sm_120 requires CUDA 12.8+. nixpkgs' default cudaPackages is intentionally held back on the 12.x line, so you have to declare cudaCapabilities = ["12.0"] explicitly. The official docs' Blackwell example only covers sm_100 (datacenter); consumer sm_120 is a blind spot.
llama.cpp wants arch 120a. Plain 120 throws a ptxas error on MXFP4. Ollama is in the same blast radius, so assume you'll verify GPU offload empirically rather than trust it works.

That's the "look it up and the answer is settled" layer. The next part is the problem.

The real boss: GSP heartbeat timeout

This is the scariest thing about 24/7 operation. The GPU's firmware (GSP) suddenly stops responding and takes the whole GPU down with it.

Symptoms are Xid 119/109/79/8, plus silent hangs that don't even emit an Xid.
It's not load-dependent — there are reports of it happening at idle. "Don't run heavy inference and you're safe" is false.
NVIDIA's own open-gpu-kernel-modules has issues #1080 / #1111 open (as of 2026-06). In other words, unresolved.

And the part that really hurts is that recovery after it happens is hell.

After a crash, a normal reset doesn't work ("WPR2 already up"). A PCI Secondary Bus Reset + module reload, or failing that a power cycle, are the only reliable ways back.
On the open driver, the classic workaround of disabling GSP is structurally impossible. NixOS hard-fails it with an assertion, and NVreg_EnableGpuFirmware=0 is ignored.

In short, "prevent it with config" isn't on the table — the reality is "if it wedges, your only option is to reboot."

So I built a watchdog that assumes it breaks

If you can't prevent it, all you can do is detect the wedge and recover automatically. Since an in-place reset doesn't work, the only reliable recovery is a reboot. I wired a declarative systemd watchdog into NixOS:

systemd = {
  services.gpu-watchdog = {
    description = "Reboot if nvidia-smi stops responding (GSP wedge)";
    path = [config.hardware.nvidia.package.bin];
    script = ''
      if ! timeout 60 nvidia-smi > /dev/null 2>&1; then
        echo "nvidia-smi unresponsive for 60s — rebooting" \
          | systemd-cat -p err -t gpu-watchdog
        systemctl reboot
      fi
    '';
    serviceConfig.Type = "oneshot";
  };

  timers.gpu-watchdog = {
    wantedBy = ["timers.target"];
    timerConfig = {
      OnBootSec = "5min";
      OnUnitActiveSec = "5min";
    };
  };
};

Every 5 minutes it pokes nvidia-smi, and if it doesn't come back within 60 seconds it declares the GPU wedged and runs systemctl reboot. It's blunt, but against an opponent where a reset doesn't work, a reboot is the most reliable move, so I made peace with it. It's unattended, so "I woke up and it was frozen" is the only thing I really need to avoid.

I also added a mitigation (anecdote-level, n=1–3): a power cap.

# RTX 5090 TDP=575W. Inference and Frigate need well under 400W.
# Idle stays ~70W regardless. This only caps peak draw.
script = ''nvidia-smi -pl 400'';

There are PSU-related Xid 119 reports around the GSP hang (cases resolved by swapping the PSU), so suppressing power spikes is reasonable. This box already runs a native ATX 3.1 1300W Platinum PSU, but I capped peak draw to keep more headroom anyway.

Would switching to Ubuntu avoid it? → No

"Wouldn't Ubuntu, with more reports out there, be more stable?" is the obvious thought, but my researched answer was No.

The GSP issue is distro-independent. It's reported on Mint, Fedora, and others, and Blackwell forces nvidia-open on every distro, so the landmine is shared. Switching to Ubuntu buys more anecdotes but doesn't avoid the crash. Trading away NixOS's rollback and declarative config for that isn't worth it.

The landing spot is the same as last time: stay on NixOS + design assuming a watchdog recovers + keep one Ubuntu Live USB for triage. Just enough of a safety net to tell "is this a GPU problem or a Nix-config problem?" when something jams.

Wrap-up

Pioneer territory — putting a latest-gen consumer GPU in a server — turns out to have reset-proof-grade landmines (the GSP heartbeat timeout) sitting right there. Since you can't prevent it with config, aiming for "it won't break" is less realistic than "assume it breaks and build automatic recovery."

And in moments like this, declarative config quietly pays off. The watchdog and the power cap all live as code in configuration.nix, so the recovery design itself becomes a reproducible asset. If the SSD dies, I can rebuild the whole catch along with it. It's the same point as the "peace of mind of rollback" from last time — the harder the pioneer territory you're crossing, the more this property earns its keep.

Whether I actually hit the moment a GSP wedge happens is something I'll find out as I run it. Once the watchdog's trigger logs start showing up, I'll add an update.

This post was written with AI assistance and reviewed by the author.