DEV Community: rbcn

Frugal Architect for SIers: Reflections from AWS GameDay

rbcn — Sun, 28 Jun 2026 15:00:45 +0000

I enjoyed GameDay this year

AWS Summit Tokyo 2026 was held over two days starting on June 25, 2026.
I joined the GameDay on Day 01. It was my first GameDay.
I also want to thank the people I briefly teamed up with that day.

The theme was Frugal Architect: the idea that, in cloud architecture, cost should not be treated as something to optimize after the fact, but as a constraint and quality attribute to be considered from the beginning of design.

This is not a GameDay walkthrough

Let me be clear up front: this article is not a GameDay walkthrough.

I will not write about the specific quests, completion conditions, resource configurations, settings, solution steps, pitfalls, scoring, or tactical observations. That would go against the spirit of the participation terms and would also spoil the experience for future participants.

What I want to write about instead is how GameDay helped me put Frugal Architect into the language of SIers—systems integrators.

In short, Frugal Architect was not a collection of cloud cost-saving tricks.

It was a vocabulary for reconnecting things that often become separated in SI projects: architecture, estimation, operations, and continuous improvement.

Frugal Architect is not merely a “cheap architect”

The word “frugal” can easily sound like “cheap” or “cost-cutting.”

But a Frugal Architect is not simply someone who chooses the cheapest possible configuration.

Anyone can make something cheaper in the short term. Remove redundancy. Reduce monitoring. Reduce logs. Remove performance headroom. Let humans compensate through operations. The monthly bill might go down.

But that is not architecture. That is just endurance.

What Frugal Architect deals with, I think, is the relationship between cost and value.

Which business value does this cost support?
Which risk does this redundancy reduce?
Which decision does this monitoring make possible?
Which user experience does this performance headroom protect?
Whose time does this operational burden consume?

In other words, the point is not to erase spending, but to make spending accountable.

In SIer language, this is the practice of connecting cost to design rationale.

In SI projects, cost is often placed outside architecture

In SI projects, the word “cost” appears constantly.

Estimates, budgets, approvals, contracts, effort, maintenance fees, cloud usage fees. Cost is everywhere.

And yet, when it comes to architecture design, cost is not always treated as a real design requirement.

Performance requirements are written down.

Availability requirements are written down.

Security requirements are written down.

Backup requirements are written down.

But cost requirements often stop at vague phrases such as “keep it as low as possible,” “stay within budget,” or “be careful with pay-as-you-go pricing.”

That is not enough to support design decisions.

Just as “make it as fast as possible” is not a performance requirement, “make it as cheap as possible” is not a cost requirement.

At minimum, cost needs to be framed in ways that architecture can actually use:

expected monthly run cost under normal conditions
which cost items increase as usage grows, and how
under what conditions cost increases are acceptable
what can and cannot be sacrificed to reduce cost
why we pay for monitoring, logs, backups, and redundancy
when and by whom cost will be reviewed after release

This is not merely a cloud billing topic.

It is a non-functional requirement that makes design decisions explainable later.

Separating initial cost and run cost is not enough

In SI estimates, it is common to separate initial build cost from operation and maintenance cost.

That distinction is necessary.

But cloud architecture requires one more step.

Cloud cost is not something fixed at build time. It continues to change with usage patterns, data volume, access patterns, log volume, backup retention, and the granularity of operational monitoring.

In other words, cloud cost is not “an amount decided during estimation.” It is a variable to be observed and adjusted during operations.

If we treat it like a fixed cost, two types of failure occur.

The first is making the initial design excessively conservative.

The second is allowing something that looked cheap at first to quietly grow during operations.

Both are familiar in SI work.

The former is called “designing on the safe side.” The latter is called “unexpected usage growth.”

From the Frugal Architect perspective, both are failures of observation and control.

FinOps is the higher-level concept; Frugal Architect is the implementation language

On reflection, I think FinOps is a higher-level abstraction than Frugal Architect.

FinOps is a management discipline for continuously aligning cloud usage, cost, and value across technology, business, finance, and operations. Cost visibility, tagging, accountability, budget management, usage analysis, and organizational decision-making all belong clearly to the FinOps domain.

Frugal Architect, on the other hand, feels closer to an implementation language for bringing that thinking into architecture.

If FinOps is the operating philosophy for making cloud usage governable, Frugal Architect is the engineer’s language for turning that philosophy into design decisions.

Which components should be synchronous?

Where should processing become asynchronous?

Where should caching be placed?

How much should be delegated to managed services?

Which logs need to be immediately searchable, and which can be retained more cheaply for later use?

Which risks are worth paying for, and which risks should be accepted operationally?

These decisions are often too late if they begin only after the invoice arrives.

At the same time, in many organizations, FinOps still seems to remain at the level of slogans and calls to action.

“Let’s optimize cloud cost.”

“Let’s make each department cost-aware.”

“Let’s add tags.”

None of these are wrong. But unless they connect to actual design decisions, FinOps ends as a slogan.

In SIer language, Frugal Architect is architecture design that includes operating cost. It is also non-functional design for bringing FinOps down into design, build, and maintenance work.

Cost is a non-functional requirement

I understand the first message of Frugal Architect as this: cost must be treated as a non-functional requirement.

For SIers, that is an important translation.

Once cost enters the category of non-functional requirements, it is no longer merely a topic for procurement, contracts, or billing.

It becomes something that can be handled in:

requirements definition
design reviews
test perspectives
operations design
acceptance criteria
improvement cycles

Simply saying “cost matters” is weak.

Saying “cost is a non-functional requirement” gives it a place in design artifacts.

For example, we can bring questions like these into non-functional requirements:

What is the unit cost of this system?
If usage doubles, does cost also double, or does it grow faster?
Who detects cost anomalies, how often, and with which metrics?
Which SLOs must be preserved when reducing cost?
Does the system need the same configuration during normal and peak periods?
For audit, investigation, and incident response, which data must be retained and at what granularity?

These questions cannot be answered by cloud architects alone.

They must be decided together with business teams, operations teams, security teams, and contract stakeholders.

That is exactly the kind of consensus-building that SIers are supposed to be good at.

Not “expensive or cheap,” but “explainable or not”

In SI work, cost reviews often become discussions about whether something is expensive or cheap.

Of course, budgets matter.

But I think the more essential question is whether the cost can be explained.

Some costs are high but explainable.

Some cost reductions are cheap but dangerous.

For example, if a redundant architecture adds cost but reduces business continuity risk, that cost can be explained. On the other hand, if unused resources or purposeless log retention continue to generate cost, even small amounts become hard to justify.

A Frugal Architect-style design review asks questions such as:

Which risk does this cost reduce?
Which customer experience does this cost protect?
Which operational task does this cost reduce?
Does this cost contribute to future changeability?
If this cost increases, can we trace why it increased?

The starting point for cloud cost design is not the amount itself, but whether the causal relationship can be traced.

Is “we cannot let the system go down” becoming an excuse for overspecification?

There is another question SIers cannot avoid.

Is the phrase “we cannot let the system go down” becoming an excuse to justify overspecification?

Of course, some systems really must not go down.

Social infrastructure, payments, healthcare, security, core business systems, customer-facing systems. If downtime would have major business or social consequences, investing in availability is absolutely reasonable.

The problem begins when “must not go down” remains undifferentiated and every component is given the same level of strength.

Which functions would truly cause business impact if they stopped?
At what time of day would downtime be most harmful?
How many minutes of downtime are tolerable?
Is degraded operation or manual fallback possible?
Would read-only operation be enough?
Which matters more: recovery time or data loss?
Does every function need the same availability level?

If these questions are not broken down, the design naturally shifts toward the safe side.

Designing on the safe side is not evil. But the cost is transferred somewhere.

It appears as infrastructure cost. It appears as operation cost. It appears as maintenance cost. Eventually, it appears in service pricing or customer burden.

In other words, unexplained availability leads to unexplained price increases.

What Frugal Architect asks is not “do not make systems highly available.”

It asks:

“What business value does this availability protect?”

“How much is the business, or the user, willing to pay for it?”

“Can the same purpose be met through a cheaper architecture, operation model, or graceful degradation design?”

Availability is not sacred. It is a non-functional requirement, and therefore a trade-off.

That is why we need to distinguish between availability that must not be cut and availability that has simply been overbuilt.

It takes courage to cut, and courage not to cut

Observability is important.

But before observability, we need the attitude to decide what to cut and what not to cut.

It takes courage to cut.

Review a configuration that has been running for a long time. Reduce resources that had extra headroom. Stop excessive retention or excessive redundancy. Delete things that are no longer used. These are not merely cost-reduction tasks. They are acts of questioning things that had quietly become sources of reassurance: “Do we really need this?”

It also takes courage not to cut.

When a cost-reduction mandate becomes strong, it is tempting to cut whatever produces visible short-term savings: monitoring, logs, backups, redundancy, security, test environments. But if those things support incident response, auditability, recovery, or customer trust, then the decision not to cut them also needs accountability.

In other words, a Frugal Architect is not “someone who cuts.”

A Frugal Architect cuts what should be cut and keeps what should be kept.

Observability is needed to support that judgment.

It is not that we cannot cut because we cannot see. Cutting while blind is dangerous.

It is not that we should keep things because we cannot see. Keeping things while blind preserves overspecification.

Observability is not the goal. It is the prerequisite that supports the courage to cut and the courage not to cut.

Practice means making small improvements repeatable

One thing GameDay made very clear to me was that cost optimization is never a one-shot activity.

We should not try to guess the perfect architecture from the beginning.

Observe. Form a hypothesis. Make a small change. Watch the impact. Move to the next improvement.

That loop matters.

In SI projects, the center of gravity changes after release.

The build team leaves, and the operations and maintenance team takes over. The original design intent fades. Even when there is room for improvement, the system can fall into a state of “it is stable, so do not touch it.”

But in the cloud, “running stably” and “running at an appropriate cost” are different things.

This is where operations and maintenance can create new value.

Not merely preventing incidents, but continuously improving the cost efficiency of systems that keep running.

This can be incorporated into monthly reports and regular meetings:

major cost changes from the previous month
relationship between usage and cost
review of unused or underused resources
validity of log, backup, and data retention policies
small optimization experiments for the next month
costs that were intentionally not reduced, and why

When these items become part of regular operational reporting, maintenance changes from “keeping the system from stopping” to “improving cost per value.”

Practices SIers can take back to real projects

Without touching specific GameDay content, I think SIers can bring the following practices back to real projects.

1. Add a cost section to non-functional requirements

Cost should not live only in a separate estimate sheet. It should be part of non-functional requirements.

What needs to be written is not only the amount.

Write the unit cost, growth factors, monitoring method, qualities that must be preserved during cost reduction, and review frequency.

2. Record cost rationale in architecture decision records

In ADRs, record not only performance, availability, and security rationale, but also cost rationale.

If we leave behind why this architecture was chosen, why this headroom was included, or why we intentionally did not optimize something yet, we can revisit those decisions later.

3. Treat tagging as accountability design, not billing management

Tags are not only for splitting invoices.

They are a design for accountability: who will look at this, who will fix it, and which service, environment, or role it belongs to.

4. Do not decide logging and monitoring by “more is safer”

More logs and metrics are not automatically better.

Define the required visibility and retention period. Separate what must be queryable immediately from what only needs to be available later.

5. Include continuous cost improvement in operations and maintenance

Do not treat cloud cost review as a special task after an incident or budget problem.

Make it part of monthly or quarterly operations.

6. Make both “costs to cut” and “costs not to cut” explicit

Cost optimization is not only about deciding what to cut. It is also about deciding what not to cut.

It takes courage to cut, and courage not to cut.

Costs that support security, auditability, availability, recoverability, and other business-critical qualities should be explained as investments, not treated as automatic reduction targets.

My biggest takeaway

My biggest takeaway was that Frugal Architect is not merely a set of optimization techniques for cloud engineers. It is a language of design responsibility.

SIers stand in a position where they must handle the customer’s business, budget, risk, operations model, contracts, and future changes together.

In that sense, Frugal Architect fits SI work very well.

But if we reduce it to “we can lower your AWS cost,” it becomes shallow.

The real value lies in being able to discuss these questions with the customer:

How much are we willing to pay for each quality attribute?
How much are we willing to pay for each risk reduction?
How should we prepare for future growth?
Which costs should we reduce now?
Which costs should we keep for future flexibility?

Making these questions a shared language across design, estimation, and operations is, to me, the SIer-style practice of Frugal Architect.

Closing

AWS GameDay was a place where I could experience architectural thinking by actually doing things with my hands.

But its value was not in learning “what to configure and how.” It was in physically understanding why certain decisions matter.

Treat cost as a non-functional requirement.

Connect cost to business value.

Observe, explain, and continuously adjust cost.

This is not a bag of cloud tricks. It is a design attitude that SI work will increasingly need.

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

Frugal Architect for SIers: Reflections from AWS GameDay

I enjoyed GameDay this year

This is not a GameDay walkthrough

Frugal Architect is not merely a “cheap architect”

In SI projects, cost is often placed outside architecture

Separating initial cost and run cost is not enough

FinOps is the higher-level concept; Frugal Architect is the implementation language

Cost is a non-functional requirement

Not “expensive or cheap,” but “explainable or not”

Is “we cannot let the system go down” becoming an excuse for overspecification?

It takes courage to cut, and courage not to cut

Practice means making small improvements repeatable

Practices SIers can take back to real projects

1. Add a cost section to non-functional requirements

2. Record cost rationale in architecture decision records

3. Treat tagging as accountability design, not billing management

4. Do not decide logging and monitoring by “more is safer”

5. Include continuous cost improvement in operations and maintenance

6. Make both “costs to cut” and “costs not to cut” explicit

My biggest takeaway

Closing

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

`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