DEV Community: rbcn

Constraints Are Interfaces: What the TrackPoint Teaches About Tool Design

rbcn — Fri, 19 Jun 2026 01:09:49 +0000

The ThinkPad That Was Supposed to Be a Side Machine

I bought a cheap used laptop as a casual work machine.

It was a ThinkPad X1 Carbon Gen 7. I installed Linux Mint and meant to use it as a secondary machine: light research, writing, a bit of work on the go. Nothing more than that.

Then it turned out to be better than expected.

Thin. Light. Good keyboard. Linux Mint ran without much drama. For a corporate lease-return laptop, it was not living out its retirement. It was still a perfectly capable working machine. Before I knew it, the side machine had become my main one.

But one thing kept bothering me.

The touchpad.

Sometimes Convenience Gets in the Way

The touchpad itself was not bad.

If anything, it was normally useful. It scrolls. It handles fine movements. On a modern laptop, it is the expected pointing device.

But in my own use, misfires started to stand out.

While writing, my palm or the base of my thumb would touch it without me noticing. The cursor would jump. I would type into the wrong place. A selection would change unexpectedly.

A small accident.

But for a machine used mainly for writing, it mattered.

Then I remembered something.

My first laptop had also been a ThinkPad: an IBM ThinkPad R31. Back then, there was no giant modern touchpad experience. There was a red dot in the middle of the keyboard, and you moved the pointer by pushing it.

So maybe I should simply go back.

Disable the touchpad. Return to the TrackPoint.

At First, It Was Just touchpad-off

The first step was simple.

I checked the touchpad name with xinput list.

SYNA8004:00 06CB:CD8B Touchpad

Then I disabled it.

xinput disable "SYNA8004:00 06CB:CD8B Touchpad"

That alone changed the feel of the machine.

My hands stayed near the home position. Pointer movement converged on the red dot. As a writing machine, the whole posture became more consistent.

At first, I treated this as a simple toggle.

#!/usr/bin/env bash
xinput disable "SYNA8004:00 06CB:CD8B Touchpad"

And if needed, turn it back on.

#!/usr/bin/env bash
xinput enable "SYNA8004:00 06CB:CD8B Touchpad"

This was the world of touchpad-off.sh and touchpad-on.sh.

At that point, it was still just a convenience setting.

Colliding with an Old X11 UX

But disabling the touchpad was not the end of it.

To scroll with the TrackPoint, you hold the middle button and push the red dot. That gesture is very ThinkPad-like. But on Linux / X11, the middle button also has another meaning.

Middle-click paste.

select text
↓
it enters PRIMARY selection
↓
middle click
↓
paste

This is an old X11 convenience. For people who know and use it, it is fast. But it was not part of the UX I had internalized when I first used a ThinkPad on Windows XP.

For my body, the middle button was not a paste button.

It was the button for TrackPoint scrolling.

So accidents happened.

I would be reading code or text. I would scroll. Some text I had selected somewhere would be pasted unexpectedly. Different from cursor jumps, but still another kind of input-path noise.

I could not simply kill the middle button itself. I needed it for scrolling.

The thing to kill was not the button, but its interpretation as paste.

xfconf-query -c xsettings -p /Gtk/EnablePrimaryPaste -n -t bool -s false 2>/dev/null \
  || xfconf-query -c xsettings -p /Gtk/EnablePrimaryPaste -s false

However, this only expressed a policy for GTK / Xfce applications. It did not remove middle-click paste from X11 as a whole. Electron apps, terminals, and some editors could still interpret Button2 on their own.

So in the end, I stopped delivering Button2 from the TrackPoint device to applications.

xinput set-button-map "TPPS/2 Elan TrackPoint" 1 0 3 4 5 6 7

The 0 means: do not send the middle button to applications. At the same time, libinput can still keep that physical button as the modifier for TrackPoint scrolling.

xinput set-prop "TPPS/2 Elan TrackPoint" "libinput Scroll Method Enabled" 0 0 1
xinput set-prop "TPPS/2 Elan TrackPoint" "libinput Button Scrolling Button" 2

Now the middle button remains for scrolling. Middle-click paste is sealed away. Paste is consolidated into Ctrl+V / Ctrl+Shift+V.

It Became Mode-In

At this point, what I was doing was no longer just turning the touchpad on and off.

Disable the touchpad
Disable PrimaryPaste
Fix the TrackPoint as the primary input device
Keep the middle button for scrolling
Stop delivering Button2 to applications
Move paste into explicit keyboard shortcuts

This was a transition into an input mode.

So I renamed the script.

Not touchpad-off.sh, but thinkpadder-mode-in.sh.

#!/usr/bin/env bash
set -euo pipefail

TOUCHPAD="SYNA8004:00 06CB:CD8B Touchpad"
TRACKPOINT="TPPS/2 Elan TrackPoint"
PRIMARY_PASTE="/Gtk/EnablePrimaryPaste"

xinput disable "$TOUCHPAD" 2>/dev/null || true

xfconf-query -c xsettings -p "$PRIMARY_PASTE" -n -t bool -s false 2>/dev/null \
  || xfconf-query -c xsettings -p "$PRIMARY_PASTE" -s false

if xinput list --name-only | grep -Fxq "$TRACKPOINT"; then
  xinput set-prop "$TRACKPOINT" "libinput Scroll Method Enabled" 0 0 1 2>/dev/null || true
  xinput set-prop "$TRACKPOINT" "libinput Button Scrolling Button" 2 2>/dev/null || true
  xinput set-button-map "$TRACKPOINT" 1 0 3 4 5 6 7 2>/dev/null || true
fi

Then I registered it with Xfce autostart.

[Desktop Entry]
Type=Application
Name=ThinkPadder Mode In
Comment=Enter TrackPoint-first ThinkPad input mode
Exec=/home/rbcn2000/.local/bin/thinkpadder-mode-in.sh
OnlyShowIn=XFCE;
X-GNOME-Autostart-enabled=true
Terminal=false

Once the machine starts, it enters ThinkPadder Mode automatically.

Constraints Are Interfaces

This is not for everyone.

Many people are better off with the touchpad. Some people love X11 middle-click paste. Some people want the escape route visible at all times.

But for me, cutting off the retreat and fixing the operation path was rational.

I wanted fewer misfires. I wanted a stable input posture. I wanted to return to a TrackPoint-centered bodily feel. For that goal, reducing options was not merely making the machine less convenient.

The constraint was the interface.

UX is not only about adding what users can do. Sometimes the body stops hesitating because something becomes impossible. Disable the touchpad, and the hand returns to the red dot. Stop delivering Button2 to applications, and the middle button becomes trustworthy as a scrolling modifier.

Customization is not only about making the tool adapt to you.

There is also a kind of customization where you make your body adapt to the tool's philosophy.

The TrackPoint is not a substitute for a mouse.

It is an extension of the keyboard.

If you see it that way, disabling the touchpad is not just nostalgia. It is a way to govern input paths and support embodied use.

This essay looked at TrackPoint UX through the lens of constraints and embodied tool design.

The more personal memory behind the same experience is here.

→ https://fragmentofview.rbcn.cc/posts/en/red-dot-in-the-middle-touchpad/

Japanese version:

→ https://emptytheory.rbcn.cc/ja/constraints-are-interfaces-trackpoint-ux/

Running Obsidian Community Plugins in Flatpak — Battle Notes and a Move to AppImage

rbcn — Sun, 14 Jun 2026 15:33:28 +0000

Introduction

For a while now, I've been running Obsidian in Flatpak on Linux.

The reason was simple: easier package management, a clean system thanks to sandboxing, and better update discipline than dropping a random binary into /usr/local/bin. For a proprietary app like Obsidian that ships its own distribution, Flatpak just makes sense. That was all there was to it.

Then I started using community plugins seriously — and everything changed.

Git sync, AI coding assistance, local CLI integration: almost every plugin that does something interesting assumes it can spawn subprocesses in the same environment as your shell. Flatpak's sandbox quietly breaks that assumption.

This is the battle log.

Flatpak's Sandbox Looks Transparent. It Isn't.

Let me set the stage.

Flatpak runs applications in an isolated sandbox. Your home directory is mounted. The network works by default. In day-to-day use you barely notice the sandbox at all.

The problems start when an app tries to spawn a subprocess.

What Flatpak restricts:
  - Process namespace (isolated from host processes)
  - Filesystem (only explicitly granted paths are accessible)
  - Environment variables (host shell settings don't reach the sandbox)

What Flatpak passes through:
  - Network (allowed by default)
  - Home directory (mounted)

"The file is right there but I can't execute it." "The command exists but it's not in PATH." These are classic Flatpak symptoms, born from this gap. Error messages often don't surface either, which makes debugging hard.

Battle One: Obsidian Git and the SSH Agent

The first wall was SSH authentication in Obsidian Git.

Connecting to GitHub from the terminal worked fine. But the Obsidian Git plugin kept asking for a passphrase, or failing authentication entirely.

The cause was the reach of SSH_AUTH_SOCK.

When you start ssh-agent in a terminal, the SSH_AUTH_SOCK it exports only reaches that shell's child processes. Flatpak Obsidian, launched from the GNOME app launcher, sits outside that process tree entirely.

Terminal's ssh-agent
  └─ terminal process
      └─ zsh (SSH_AUTH_SOCK is set)
                              ← wall is here
Flatpak Obsidian (SSH_AUTH_SOCK never arrives)

I tried unifying everything through GNOME Keyring (gcr), but ran into a different problem: gcr-ssh-agent hung during the signing operation in a way I couldn't reliably fix.

The solution that stuck was running OpenSSH ssh-agent as a systemd user service, giving it a fixed socket path that exists before any shell or GUI app starts.

# ~/.config/systemd/user/ssh-agent.service
[Unit]
Description=OpenSSH key agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a %t/ssh-agent.socket

[Install]
WantedBy=default.target

With a fixed socket at /run/user/1000/ssh-agent.socket, I could expose it to Flatpak explicitly and reference it in a dedicated Obsidian Git wrapper script with SSH_AUTH_SOCK and BatchMode=yes hardcoded.

The full story is in the previous post:
→ Migrating to zsh Broke Obsidian Git — A Battle with SSH Agent and Flatpak

Battle Two: The Codex CLI and stdio JSON-RPC

With SSH sorted, things were stable for a while. Then AI plugin integration became my next problem.

When you use AI coding assistance inside Obsidian, how it works depends entirely on the plugin — and the differences matter a lot in Flatpak.

Plugin + Integration	Transport	CLI runtime	Flatpak impact
Smart Composer + Codex	HTTP API (REST)	—	Network works → no problem
Claudian + Claude Code	stdio JSON-RPC	Bun standalone ELF (self-contained)	Worked from day one
Claudian + Codex CLI	stdio JSON-RPC	Node.js script (`#!/usr/bin/env node`)	Broke

Smart Composer with a Codex subscription worked out of the box because it calls the OpenAI REST API over the network. Flatpak doesn't block network access.

Claudian's Codex integration didn't, because it spawns the local codex CLI as a subprocess and communicates over stdio using JSON-RPC.

Claudian plugin
  → spawn: codex app-server --listen stdio://
  → JSON-RPC over stdin/stdout

I Wrote a Wrapper Script

To call /home/rbcn2000/.npm-global/bin/codex from inside Flatpak, I needed flatpak-spawn --host to launch it as a host-side process. My first attempt:

#!/usr/bin/env zsh

exec flatpak-spawn --host zsh -i -c '/home/rbcn2000/.npm-global/bin/codex "$@"' -- "$@"

The -i (interactive) flag was there to load .zshrc and get nvm's Node.js into PATH. That was the mistake.

`zsh -i` Poisons stdout

I set this as the Codex CLI path in Claudian's settings. The integration still didn't work. No error message.

Here's why.

zsh -i starts as an interactive shell, which means it executes .zshrc in full. My .zshrc includes:

eval "$(zoxide init zsh)"     # may write to stdout
eval "$(starship init zsh)"   # writes initialization output to stdout
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

Claudian's Codex integration starts reading stdout as a JSON-RPC stream the moment the process launches.

Expected stdout:
  {"jsonrpc":"2.0","id":1,"result":{...}}

Actual stdout:
  (starship / zoxide initialization output)
  {"jsonrpc":"2.0","id":1,"result":{...}}

The JSON parser fails on the first non-JSON line. The connection drops. The error is reported as "could not connect" — with no hint about what was on stdout. The root cause is invisible.

The Fix: Remove the Intermediate Shell

#!/usr/bin/env bash

HOST_PATH="/usr/bin:/usr/local/bin:/home/rbcn2000/.npm-global/bin:$PATH"

exec flatpak-spawn --host env PATH="$HOST_PATH" \
  node /home/rbcn2000/.npm-global/lib/node_modules/@openai/codex/bin/codex.js "$@"

Three changes:

No intermediate shell — nothing can pollute stdout
node called directly — skips symlink resolution and shebang lookup
PATH built explicitly for the host — Flatpak's sandbox PATH doesn't include /usr/bin or npm-global, so I assemble the environment that flatpak-spawn --host will pass to the host process myself

That worked.

Why Claude Code Worked From the Start

It's worth asking why Claudian's Claude Code integration never needed any of this. The answer is a fundamental difference in how the two tools are built.

Inspecting the Claude Code binary:

$ file ~/.local/share/claude/versions/2.1.177
ELF 64-bit LSB executable, x86-64, dynamically linked

$ ldd ~/.local/share/claude/versions/2.1.177
  librt.so.1, libc.so.6, libpthread.so.0, libdl.so.2, libm.so.6

$ ls -lh ~/.local/share/claude/versions/2.1.177
-rwxr-xr-x  239M  claude

Dependencies: only libc family. No libnode.so. No libv8.so. Size: 239 MB.

This is the signature of a Bun bun build --compile standalone ELF. Bun statically bundles its JavaScript engine (JavaScriptCore) directly into the binary at compile time. The result needs no external Node.js runtime — it's fully self-contained.

Claude Code (Bun standalone):
  ELF binary
    └─ JavaScriptCore (statically bundled)
    └─ application code (statically bundled)
  → doesn't care what's in PATH
  → runs from anywhere, including Flatpak's sandbox

Codex CLI (Node.js script):
  codex.js  ← #!/usr/bin/env node
    → looks up `node` in PATH at runtime
    → nvm's node isn't in Flatpak's PATH
    → fails

If Codex moves to a native Rust binary, the story changes again. A Rust binary is also self-contained, with no external runtime dependency. The wrapper problem would simply disappear.

The discussion of "Claude Code is Bun, Codex is moving to Rust" has been floating around lately — but for Flatpak users, it maps directly onto a concrete lived experience: why did one work and the other didn't? An abstract build-system choice showed up as the difference between "works on first try" and "two hours of silent debugging."

Why Community Plugins Don't Handle Flatpak

After these two battles, the structural reasons became clear.

① Flatpak Obsidian users are a thin slice of a thin slice

Linux desktop users are a minority among Obsidian's userbase. Flatpak Obsidian users are a minority among Linux desktop users. If you're a plugin developer on macOS, Windows, or even a .deb/AppImage Linux setup, you'll never encounter Flatpak's behavior. There's no incentive to test for it.

② Flatpak failures are invisible

command not found or permission denied are easy to debug. Flatpak problems tend to appear as timeouts and silent connection failures — exactly the symptoms both of my issues produced. It's hard to file a useful bug report for "it just doesn't connect," and hard for a developer to reproduce without a Flatpak environment.

③ Plugins assume "same environment as the shell"

Any plugin that spawns a subprocess implicitly assumes that PATH, environment variables, and sockets like SSH_AUTH_SOCK have the same values as in a terminal session. Flatpak silently breaks that assumption.

The Decision: Move to AppImage

Every workaround I added made the overall setup more fragile.

For SSH agent: a systemd service, a wrapper script, a .desktop file override
For Codex CLI: a flatpak-spawn wrapper, manually assembled PATH

Each fix is correct in isolation. Together, they form a web of dependencies where changing one thing can break another. Upgrade nvm → PATH shifts. Adjust systemd → socket path changes.

AppImage is a different approach. It doesn't sandbox anything. It runs as a regular process in the host environment, inheriting your PATH, your SSH_AUTH_SOCK, your nvm — everything.

AppImage Obsidian:
  PATH              → inherited from host
  SSH_AUTH_SOCK     → inherited from host
  subprocess spawn  → runs in host environment
  flatpak-spawn     → not needed

The maintenance calculus has flipped. AppImage is now the simpler choice.

Takeaways

Pushing Flatpak Obsidian to its limits produced two real lessons:

SSH agent: Environment variables don't teleport — they propagate through process inheritance. A socket that works in your terminal doesn't exist in a GUI app spawned from a launcher. Anchoring the agent to a fixed path via systemd removes the dependency on how the app was launched.

Codex CLI / stdio JSON-RPC: When a plugin communicates over stdio as a protocol, the spawned process must produce nothing but protocol output. An interactive shell between the plugin and the binary is a silent killer — init scripts write to stdout, the JSON parser fails, the connection drops with no error trace.

Neither failure was Flatpak's fault. Flatpak sandboxed exactly what it was supposed to sandbox. The failure was in not accounting for those boundaries earlier.

Never put an interactive shell between a caller and a subprocess that uses stdio as a protocol.

That's the single most concrete rule I can extract from this.

And the broader one: workarounds compound. At some point, the maintenance cost of staying exceeds the switching cost of leaving. Moving to AppImage is an acknowledgment of reaching that point.

I Built a Pipeline to Publish This Post.

rbcn — Sat, 30 May 2026 18:25:54 +0000

Introduction

I write in Obsidian. I publish on Hashnode. Until recently, moving between the two looked like this:

Open the vault note
Copy the content
Open Hashnode editor
Paste and reformat the frontmatter manually
Hunt for a cover image
Upload it
Hit publish

Somewhere between ten and fifteen minutes of friction between "I'm done writing" and "the post is live."

I got tired of it. So I built a pipeline.

This post documents that pipeline — and it was published through it.

The Problem with Manual Publishing

My Obsidian notes have their own frontmatter schema. Hashnode has its own. They're similar enough to feel like they should be the same thing, and different enough that copy-pasting always broke something.

The tags format was different. The title needed quoting sometimes and not others. The cover image had to be uploaded separately. The ## 📝 Draft section header had to be stripped out.

None of these are hard problems. But they were the kind of small, repetitive friction that makes you skip publishing altogether.

The Architecture

The pipeline has three components:

04_Publish note  (Obsidian vault)
  ↓
/hashnode-publish  (Claude Code skill)
  converts frontmatter, generates slug, writes file
  ↓
post/<timestamp>/slug.md  (GitHub relay repo)
  ↓  git push → GitHub Actions
  ├─ Resolve Unsplash cover image
  └─ Hashnode API  →  live post

Each component has a single responsibility. The vault stays clean. The publishing logic lives outside it.

Component 1: The GitHub Relay Repo

The first piece is a GitHub repository whose only job is to receive markdown files and forward them to Hashnode.

The GitHub Actions workflow triggers on any push that touches post/**/*.md. The nested path pattern matters — post/*.md wouldn't match, so every article goes into a timestamp-named subfolder: post/20260517143000/slug.md. That folder name also serves as a natural ordering key.

When the workflow fires, it runs two steps per changed file:

Resolve Unsplash cover image — more on this below.
Hashnode publish — calls the Hashnode API via raunakgurud09/hashnode-publish@v1.1.

The Hashnode API key lives in GitHub Secrets. It never touches the local machine.

Component 2: The Claude Code Skill

The second piece is a Claude Code slash command: /hashnode-publish.

When invoked, it reads the current vault note, parses its frontmatter, and converts it to Hashnode's format. Then it generates a slug from the filename, creates the timestamp folder, writes the converted file, and pushes to the relay repo.

The frontmatter conversion handles the differences between the vault schema and Hashnode's schema: tag format, field ordering, stripping vault-specific fields, dropping the ## 📝 Draft header from the body. If description is empty, it stops and asks to fill it in first. If publish is false, it warns before proceeding.

From the writer's perspective, the workflow becomes:

1. Write the note in Obsidian
2. Fill in the frontmatter (title, description, tags, etc.)
3. Type /hashnode-publish
4. Done

The entire publishing process — conversion, file creation, commit, push — runs in under ten seconds.

Component 3: Unsplash Cover Images

The third piece solves the cover image problem.

The vault frontmatter accepts a splash_keyword field. When it's set and cover_image is empty, the skill passes the keyword through to the relay repo file. GitHub Actions picks it up, calls the Unsplash API, and injects the result as cover_image before passing the file to Hashnode.

# In the vault note frontmatter
splash_keyword: "developer workspace"
cover_image: ""

GitHub Actions:
  splash_keyword found → GET /photos/random?query=developer+workspace
  → cover_image: https://images.unsplash.com/photo-...
  → splash_keyword removed from frontmatter

The Unsplash API key lives in GitHub Secrets alongside the Hashnode key. Nothing sensitive is stored locally.

One more thing: the Unsplash API terms encourage attribution. So whenever an image is fetched, the workflow appends a line to the article body:

*cover image: [unsplash](https://unsplash.com/)*

The cover image for this post was chosen by that step. I wrote splash_keyword: "developer workspace" and the algorithm did the rest.

The Decision to Use a Relay Repo

A simpler design would call the Hashnode API directly from the Claude Code skill. No relay repo, no GitHub Actions — just a local script with the API key.

I chose the relay repo approach for one reason: the API keys live in GitHub Secrets, not on the local machine.

This matters more than it might seem. A Claude Code skill runs with access to the local environment. Keeping secrets out of that environment, and inside a CI/CD system with audit logs and rotation tooling, is a better default. The relay repo adds one step but removes a category of risk.

There's a secondary benefit: the relay repo is a record. Every published post has a corresponding commit with a timestamp and a slug. That's useful.

What the Frontmatter Looks Like

A complete vault note ready for publishing looks like this:

---
title: "Post Title."
subtitle: "Subtitle here."
tags: ["tag1", "tag2"]
description: "One or two sentences describing the post."
cover_image: ""
splash_keyword: "relevant search term"
publish: true
enableTableOfContent: true
isNewsletterActivated: true
---

Three fields drive the cover image behavior:

`cover_image`	`splash_keyword`	Result
set	—	Use the URL directly
empty	set	Fetch from Unsplash
empty	empty	No cover image

Lessons

The friction between "done writing" and "published" is a publishing problem, not a writing problem.

Optimizing the writing environment — better tools, better structure — doesn't help if the last mile is still manual. The pipeline had to be built separately.

And a pattern that recurred across all three components:

Put secrets where they belong. API keys in GitHub Secrets, not environment variables, not shell configs.

It's the same principle that came up in the SSH agent post: scope matters. A credential should only be reachable from the system that actually needs to use it.

What's Next

The pipeline is functional. A few things I'd add eventually:

Update existing posts: the current workflow only handles new files; updating a published post requires a separate flow
Preview step: see the formatted output before pushing
Japanese articles: the same pipeline works, but slug generation from Japanese filenames needs a romanization step

For now, typing /hashnode-publish and watching the commit appear in the relay repo is satisfying enough.

Migrating to zsh Broke Obsidian Git.

rbcn — Sat, 30 May 2026 17:53:20 +0000

Introduction

In the previous post, I quit .bashrc and gave bash and zsh separate responsibilities. The terminal environment was clean.

The next day, I opened Obsidian and Git sync had stopped.

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

It looked like "switching to zsh broke Obsidian." But the shell wasn't the real culprit.
The ssh-agent's scope simply wasn't reaching GUI applications.

This is the record of how I tracked down that cause and fought my way through the Flatpak sandbox to fix it.

The Structure of the Problem

Checking from the terminal, the SSH keys were visible.

echo "$SSH_AUTH_SOCK"   # /run/user/1000/gcr/ssh
ssh-add -l              # work-github / personal-github

Yet Obsidian Git plugin kept asking for a passphrase every single time.

Terminal (zsh) → OK
Obsidian (GUI) → NG

The problem broke down like this:

ssh-agent launched from a shell
  → only valid within that shell's process tree

Obsidian launched by the GUI
  → never reads .zshrc
  → never reaches the ssh-agent

In other words, this wasn't a shell configuration problem — it was a login session design problem.

Why Did It Work Before?

A question immediately surfaced: when everything was crammed into .bashrc, Obsidian Git worked fine. Why?

The answer turned out to involve GNOME Keyring (gcr).

gcr-ssh-agent integrates with the GNOME login session and automatically exposes SSH keys when the login keyring is unlocked. That meant Obsidian had always been talking to gcr directly, without going through the shell at all.

It wasn't that passphrases were unnecessary — it was that GNOME Keyring had been silently providing the previously-saved passphrase all along.

Attempting gcr-ssh-agent Unification (and Failing)

My first plan was to leverage this mechanism and route everything through gcr.

gcr-ssh-agent
  → /run/user/1000/gcr/ssh
  → shared by Terminal / Editor / Obsidian / Flatpak

I exposed the gcr socket to the Flatpak Obsidian sandbox.

flatpak override --user \
  --filesystem=xdg-run/gcr \
  --env=SSH_AUTH_SOCK=/run/user/1000/gcr/ssh \
  md.obsidian.Obsidian

It worked — temporarily. GitHub authentication went through.

Then I rebooted. The problem came back.

Signing hangs

ssh-add -l              # personal-github / work-github → visible
ssh -T github-personal  # → hangs (no response)

The verbose log showed GitHub was accepting the key.

Offering public key: id_ed25519_personal
Server accepts key: id_ed25519_personal
signing using ssh-ed25519   ← hangs here

The signing request sent to gcr-ssh-agent was never coming back.

Keys resurrect after `ssh-add -D`

ssh-add -D   # All identities removed.
ssh-add -l   # personal-github / work-github  ← instantly back

gcr was auto-publishing keys from its keyring storage. And that auto-restored state was broken for signing.

Cleaning up via Seahorse was risky

When I tried to delete SSH key entries in Seahorse (GNOME's keyring manager), I realized it looked like it would delete the actual private key files (~/.ssh/id_ed25519_personal) along with them.

That was the end of the gcr unification attempt.

What Remained Unexplained

I never found the root cause of gcr-ssh-agent's signing hang. Here's what I was able to rule out:

The key files were not corrupted
The public keys on GitHub were registered correctly
Exposing the Flatpak socket was not the sole cause
~/.ssh/config Host aliases were not misconfigured

→ gcr-ssh-agent's auto-restored state was unstable at signing time
→ Root cause: unknown

This isn't a verdict that gcr-ssh-agent is broken. This problem happened in this environment. Given that, I chose to prioritize determinism and switch to OpenSSH ssh-agent.

Pinning OpenSSH ssh-agent as a systemd User Service

I decided to manage a plain OpenSSH ssh-agent with a fixed socket path under systemd user.

mkdir -p ~/.config/systemd/user

cat > ~/.config/systemd/user/ssh-agent.service <<'EOF'
[Unit]
Description=OpenSSH key agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a %t/ssh-agent.socket

[Install]
WantedBy=default.target
EOF

systemctl --user daemon-reload
systemctl --user enable --now ssh-agent.service

The socket is now pinned at /run/user/1000/ssh-agent.socket.

Updating `~/.ssh/config`

I added explicit IdentityAgent directives so SSH connections don't depend on the current value of SSH_AUTH_SOCK.

Host github-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_personal
    IdentitiesOnly yes
    AddKeysToAgent yes
    IdentityAgent /run/user/1000/ssh-agent.socket

Host github-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes
    AddKeysToAgent yes
    IdentityAgent /run/user/1000/ssh-agent.socket

Normalizing the socket in bash and zsh

Added to both .bashrc and .zshrc:

# OpenSSH ssh-agent (shared between .bashrc and .zshrc)
if [ -S "$XDG_RUNTIME_DIR/ssh-agent.socket" ]; then
  export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"
fi

Dealing with Flatpak

Flatpak's Obsidian runs inside its own sandbox. The host socket needs to be explicitly exposed.

flatpak override --user \
  --filesystem=xdg-run/ssh-agent.socket \
  --env=SSH_AUTH_SOCK=/run/user/1000/ssh-agent.socket \
  md.obsidian.Obsidian

# Remove gcr access
flatpak override --user \
  --nofilesystem=xdg-run/gcr \
  md.obsidian.Obsidian

The Obsidian Git wrapper

Since the Obsidian Git plugin uses /app/bin/git inside the Flatpak, I wrapped it.

cat > ~/.local/bin/obsidian-git <<'EOF'
#!/usr/bin/env bash

SOCK="/run/user/1000/ssh-agent.socket"

export SSH_AUTH_SOCK="$SOCK"
export GIT_SSH_COMMAND="ssh \
  -F /home/rbcn2000/.ssh/config \
  -o IdentityAgent=$SOCK \
  -o BatchMode=yes \
  -o ConnectTimeout=10 \
  -o ServerAliveInterval=5 \
  -o ServerAliveCountMax=1"

exec /app/bin/git "$@"
EOF

chmod +x ~/.local/bin/obsidian-git

BatchMode=yes is the critical part — it prevents the automated commit/sync process from silently hanging while waiting for a passphrase prompt that can never appear.

In the Obsidian Git plugin settings, set Custom Git binary path to /home/rbcn2000/.local/bin/obsidian-git.

Automating Key Loading After Reboot

Unlike gcr, OpenSSH ssh-agent does not restore keys automatically. After a reboot, the agent starts empty.

I considered bringing keychain back, but decided against it — it risks creating duplicate agents. Instead, I wrote a minimal script whose only job is loading the keys.

cat > ~/.local/bin/ssh-load-github <<'EOF'
#!/usr/bin/env bash

set -u

SOCK="/run/user/1000/ssh-agent.socket"
export SSH_AUTH_SOCK="$SOCK"

if [ ! -S "$SOCK" ]; then
  systemctl --user start ssh-agent.service 2>/dev/null || true
fi

if [ ! -S "$SOCK" ]; then
  echo "ssh-agent socket not found: $SOCK" >&2
  exit 1
fi

# Don't wait for passphrase input in non-interactive environments
if [ ! -t 0 ]; then
  exit 0
fi

CURRENT_KEYS="$(ssh-add -l 2>/dev/null || true)"

if ! printf '%s\n' "$CURRENT_KEYS" | grep -q 'personal-github'; then
  ssh-add "$HOME/.ssh/id_ed25519_personal" || exit 1
fi

CURRENT_KEYS="$(ssh-add -l 2>/dev/null || true)"

if ! printf '%s\n' "$CURRENT_KEYS" | grep -q 'work-github'; then
  ssh-add "$HOME/.ssh/id_ed25519_work" || exit 1
fi
EOF

chmod +x ~/.local/bin/ssh-load-github

Call it from .zshrc and .bashrc on interactive shell startup:

if [[ $- == *i* ]] && [ -t 0 ] && [ "${SSH_LOAD_GITHUB_ON_SHELL:-1}" = "1" ]; then
  "$HOME/.local/bin/ssh-load-github" 2>/dev/null || true
fi

Now, the first time a terminal opens after reboot, you enter the passphrase once — and that's it.

The .desktop Launcher Trap

I thought it was solved. There was one more problem.

After a reboot, launching Obsidian first meant Git didn't work.

The culprit was the TTY check inside ssh-load-github:

if [ ! -t 0 ]; then
  exit 0   # No TTY → do nothing
fi

When Obsidian launches from a .desktop file, there is no TTY. So ssh-load-github exits immediately, keys never get loaded, and Obsidian starts up with an empty agent.

The fix: SSH_ASKPASS for a GUI dialog

OpenSSH has a built-in mechanism for exactly this situation: SSH_ASKPASS.

sudo apt install ssh-askpass-gnome

I wrote a dedicated launcher that uses it:

cat > ~/.local/bin/open-obsidian <<'EOF'
#!/usr/bin/env bash

SOCK="/run/user/1000/ssh-agent.socket"
export SSH_AUTH_SOCK="$SOCK"

if [ ! -S "$SOCK" ]; then
  systemctl --user start ssh-agent.service 2>/dev/null || true
fi

if [ ! -S "$SOCK" ]; then
  echo "ssh-agent socket not found: $SOCK" >&2
  exit 1
fi

# Accept passphrase input via GTK dialog even without a TTY
export SSH_ASKPASS="/usr/lib/openssh/gnome-ssh-askpass"
export SSH_ASKPASS_REQUIRE=force

CURRENT_KEYS="$(ssh-add -l 2>/dev/null || true)"

if ! printf '%s\n' "$CURRENT_KEYS" | grep -q 'personal-github'; then
  ssh-add "$HOME/.ssh/id_ed25519_personal" || exit 1
fi

CURRENT_KEYS="$(ssh-add -l 2>/dev/null || true)"

if ! printf '%s\n' "$CURRENT_KEYS" | grep -q 'work-github'; then
  ssh-add "$HOME/.ssh/id_ed25519_work" || exit 1
fi

exec flatpak run md.obsidian.Obsidian "$@"
EOF

chmod +x ~/.local/bin/open-obsidian

Overriding the .desktop file

The system-side Flatpak .desktop file can't be edited directly — Flatpak updates would overwrite it. Instead, copy it to the user applications directory and redirect the Exec line.

cp /var/lib/flatpak/exports/share/applications/md.obsidian.Obsidian.desktop \
   ~/.local/share/applications/md.obsidian.Obsidian.desktop

sed -i 's|^Exec=.*|Exec=/home/rbcn2000/.local/bin/open-obsidian %U|' \
   ~/.local/share/applications/md.obsidian.Obsidian.desktop

update-desktop-database ~/.local/share/applications/

Now, launching Obsidian from the app launcher shows a GTK passphrase dialog first, then starts Obsidian.

The Final Architecture

systemd user
  ↓
OpenSSH ssh-agent.service
  ↓
/run/user/1000/ssh-agent.socket
  ├─ bash / zsh (ssh-load-github on shell startup)
  ├─ ~/.ssh/config (IdentityAgent explicit)
  └─ ~/.local/bin/open-obsidian  ← launched from .desktop
       └─ SSH_ASKPASS=gnome-ssh-askpass (GTK dialog)
            ↓
          Flatpak Obsidian
               ↓
             ~/.local/bin/obsidian-git (BatchMode=yes)
               ↓
             /app/bin/git

After a reboot, behavior is now fully symmetric:

Opening a terminal first:
  → ssh-load-github runs
  → passphrase entered once
  → shared across bash / zsh / Obsidian for the rest of the session

Opening Obsidian first:
  → open-obsidian runs
  → GTK dialog prompts for passphrase
  → shared across bash / zsh / Obsidian for the rest of the session

Separation of Concerns

In the end, the responsibilities around ssh-agent sorted themselves into a clear table:

Responsibility	Handled by
Agent startup	systemd user `ssh-agent.service`
Agent selection	`SSH_AUTH_SOCK` / `IdentityAgent`
Key loading (terminal)	`ssh-load-github` (TTY present)
Key loading (GUI launch)	`open-obsidian` + `SSH_ASKPASS` (no TTY)
Unattended Git operations	`BatchMode=yes`

Tools like keychain that handle everything in one shot are convenient, but they make it easy to accidentally create duplicate agents or fail to reach GUI applications. Separating the responsibilities made it clear exactly what was happening at every step.

Lessons Learned

An environment variable is not a "setting" — it is the result of process inheritance.

Even if SSH_AUTH_SOCK is correctly set somewhere, it only reaches a child process if that child is spawned from a process that has it. Configuration written in .zshrc simply does not reach GUI applications. That was the root of everything.

And an additional lesson:

Sometimes a fixed socket with a simple agent is more deterministic than a polished GUI integration.

gcr-ssh-agent's desktop integration is elegant. But in this environment, its auto-restore mechanism turned out to be unstable at signing time. A plain OpenSSH ssh-agent on a fixed socket was far more predictable.

I Quit .bashrc.

rbcn — Sat, 30 May 2026 17:47:33 +0000

Introduction

One morning, the j command was gone.

I had been using it as an alias for zoxide, but suddenly it returned command not found. It worked fine in Ghostty, but not in VSCode's integrated terminal. Zed behaved differently yet again.

I had built the perfect "I can't explain why this works" environment.

This is the story of what happens when you keep piling settings into .bashrc — and what you gain when you stop.

Before: The Everything-in-.bashrc Era

When I started Linux development, I added a new line to .bashrc every time I introduced a useful tool.

# .bashrc (bloated state)
eval "$(starship init bash)"
eval "$(zoxide init bash)"
eval "$(fzf --bash)"
eval "$(keychain --quiet --eval --agents ssh id_ed25519_work id_ed25519_personal)"
source ~/.bash_aliases
export PATH="$HOME/.local/bin:$PATH"
# ... secrets, completions, etc.

Aliases, completions, environment variables, and tool initializations were all jammed into a single file.

This caused three main problems.

① PATH inconsistency

Some tools would have their paths registered and some wouldn't. Every time I opened a new terminal, things might behave differently.

② Behavioral differences across terminals

Commands that worked in Ghostty didn't work in VSCode's integrated terminal. The disappearing j command was the clearest symptom.

③ Loss of reproducibility

I could no longer explain why things worked. Was it my config? Something I ran earlier? I had no idea.

The Insight: Shell ≠ Environment

As I worked through the problem, something clicked.

Shell ≠ Environment
Shell = UI (the interface)
Environment = execution context

.bashrc had been doing two completely different jobs at once: configuring the OS-standard shell and initializing the development environment. That was the root of all the confusion.

The problem wasn't the tools themselves (zoxide, starship). It was the mixing of initialization paths. Login shells and interactive shells read different files — that discrepancy was causing the behavioral differences across terminals.

After: Decomposing into Three Layers

Based on this insight, I split the environment into three distinct layers.

bash     = OS-standard / preservation layer
zsh      = development environment layer
terminal = display layer (all unified to zsh -l)

Returning bash to a preservation layer

I reset .bashrc to the system default.

cp /etc/skel/.bashrc ~/.bashrc

The only thing I kept was an expanded HISTSIZE. All development-specific configuration was removed.

Consolidating the development environment into zsh

Development tool initialization moved to .zshrc.

# ~/.zshrc
eval "$(starship init zsh)"
eval "$(zoxide init zsh)"
source ~/.zsh_aliases
export PATH="$HOME/.local/bin:$PATH"

Aliases were also separated into .zsh_aliases.

Unifying all terminals to `zsh -l`

I updated each terminal's configuration to launch zsh as a login shell.

Ghostty

command = /usr/bin/zsh -l

VSCode

"terminal.integrated.profiles.linux": {
  "zsh": {
    "path": "/usr/bin/zsh",
    "args": ["-l"]
  }
},
"terminal.integrated.defaultProfile.linux": "zsh"

Zed (v1.0.0)

"terminal": {
  "shell": {
    "with_arguments": {
      "program": "/usr/bin/zsh",
      "args": ["-l"]
    }
  }
}

WezTerm (~/.wezterm.lua)

local wezterm = require 'wezterm'
local config = {
  default_prog = { '/usr/bin/zsh', '-l' },
  font = wezterm.font('JetBrainsMono Nerd Font'),
  font_size = 13.0,
  color_scheme = "Dracula",
  enable_tab_bar = false,
}
return config

WezTerm takes the shell and its arguments as an array via default_prog. Font settings can be unified here as well.

Gotchas Along the Way

A few things tripped me up during the migration.

Icons turn into tofu squares in VSCode only

Symptoms:

Ghostty → OK
Zed     → OK
VSCode  → icons render as □ (tofu)

The cause: VSCode has a separate font setting for its integrated terminal.

"terminal.integrated.fontFamily": "JetBrainsMono Nerd Font Mono"

Adding this line fixed it.

The display name and actual name of the font don't match

Display name: JetBrainsMono Nerd Font Mono
Actual name:  JetBrainsMono NFM

Ghostty resolves this transparently via fontconfig. WezTerm and Zed may require specifying JetBrainsMono NFM explicitly.

The `j` command disappeared

I had alias j='z' in .bash_aliases, but after migrating to zsh it needed to move to .zsh_aliases.

# ~/.zsh_aliases
alias j='z'
alias ji='zi'

`$0` and `$SHELL` show different values

echo $0      # → zsh
echo $SHELL  # → /bin/bash

$SHELL reflects the login shell, not necessarily the currently running shell. Adding this to .zshrc aligns them:

export SHELL=/usr/bin/zsh

Results

Before: everything in .bashrc → non-deterministic environment
After:  bash=preservation / zsh=development / terminal=display → determinism restored

Same environment regardless of which terminal launches it
PATH issues eliminated
Debugging scope narrowed to the application itself

The biggest win: I can now explain why things work.

Closing

Quitting .bashrc wasn't about abandoning tools.
It was about making ownership of the environment explicit.

Shell is UI. Environment is execution context. Cramming both into the same file was the source of all the confusion.

In the next post, I'll cover what happened immediately after this migration: Obsidian Git's SSH authentication broke, and I found myself in a battle with ssh-agent and the Flatpak sandbox.

DEV Community: rbcn

Constraints Are Interfaces: What the TrackPoint Teaches About Tool Design

The ThinkPad That Was Supposed to Be a Side Machine

Sometimes Convenience Gets in the Way

At First, It Was Just touchpad-off

Colliding with an Old X11 UX

It Became Mode-In

Constraints Are Interfaces

Running Obsidian Community Plugins in Flatpak — Battle Notes and a Move to AppImage

Introduction

Flatpak's Sandbox Looks Transparent. It Isn't.

Battle One: Obsidian Git and the SSH Agent

Battle Two: The Codex CLI and stdio JSON-RPC

I Wrote a Wrapper Script

zsh -i Poisons stdout

The Fix: Remove the Intermediate Shell

Why Claude Code Worked From the Start

Why Community Plugins Don't Handle Flatpak

The Decision: Move to AppImage

Takeaways

I Built a Pipeline to Publish This Post.

Introduction

The Problem with Manual Publishing

The Architecture

Component 1: The GitHub Relay Repo

Component 2: The Claude Code Skill

Component 3: Unsplash Cover Images

The Decision to Use a Relay Repo

What the Frontmatter Looks Like

Lessons

What's Next

Migrating to zsh Broke Obsidian Git.

Introduction

The Structure of the Problem

Why Did It Work Before?

Attempting gcr-ssh-agent Unification (and Failing)

Signing hangs

Keys resurrect after ssh-add -D

Cleaning up via Seahorse was risky

What Remained Unexplained

Pinning OpenSSH ssh-agent as a systemd User Service

Updating ~/.ssh/config

Normalizing the socket in bash and zsh

Dealing with Flatpak

The Obsidian Git wrapper

Automating Key Loading After Reboot

The .desktop Launcher Trap

The fix: SSH_ASKPASS for a GUI dialog

Overriding the .desktop file

The Final Architecture

Separation of Concerns

Lessons Learned

I Quit .bashrc.

Introduction

Before: The Everything-in-.bashrc Era

The Insight: Shell ≠ Environment

After: Decomposing into Three Layers

Returning bash to a preservation layer

Consolidating the development environment into zsh

Unifying all terminals to zsh -l

Gotchas Along the Way

Icons turn into tofu squares in VSCode only

The display name and actual name of the font don't match

The j command disappeared

$0 and $SHELL show different values

Results

Closing

`zsh -i` Poisons stdout

Keys resurrect after `ssh-add -D`

Updating `~/.ssh/config`

Unifying all terminals to `zsh -l`

The `j` command disappeared

`$0` and `$SHELL` show different values