Coder Legion - Recent posts tagged terminal

Keeping a Web-Backed SSH Terminal Alive Across SwiftUI Navigation

Sun, 09 Aug 2026 04:53:28 +0000

A desktop SSH client can keep the remote connection alive and still give the user the impression that the terminal was reset. The failure often sits one layer above SSH: the UI destroys and rebuilds the terminal surface when the user switches to another section.

That distinction matters when a macOS app embeds xterm.js in WKWebView. The SSH process, terminal model, WebKit process, DOM, scrollback, focus chain, and visible geometry all have different lifetimes. Treating them as one SwiftUI view makes normal navigation surprisingly destructive.

This article describes the design rules we ended up using in a native macOS SSH client.

Why rebuilding is not a harmless refresh

A straightforward SwiftUI implementation conditionally creates the selected section:

if selectedSection == .terminal {
    TerminalSurface()
} else {
    FilesView()
}

When the condition changes, SwiftUI is free to dismantle the terminal subtree. If that subtree owns a WKWebView, the app can lose much more than a view object:

the WebContent process and xterm.js DOM may be destroyed;
scrollback stored only in the browser process disappears;
alternate-screen applications such as vim, nano, or top cannot be reconstructed from plain text;
restoring a bounded output snapshot may omit older history;
WebKit initialization and snapshot replay add visible latency;
focus and resize events can arrive in a different order after reconstruction.

Keeping the SSH handle alive does not solve any of these UI-state losses. The remote PTY may still be healthy while the local terminal surface has forgotten how to represent it.

Separate four lifetimes

The useful mental model is to separate at least four things:

Logical session: the tab, server identity, name, working directory, and user-facing state.
Transport session: the SSH handle and remote PTY that carry input and output.
Terminal renderer: the WKWebView, xterm.js DOM, parser state, and scrollback.
Visible attachment: whether that renderer currently participates in the AppKit view hierarchy and responder chain.

Navigation should normally change only the fourth lifetime. Closing a tab can end all four. A network failure may replace the transport while retaining the logical tab and renderer. Conflating those transitions is where most of the surprising behavior begins.

Mount once, then deactivate

After the terminal section is opened for the first time, keep its SwiftUI subtree mounted. Other sections can still be created normally, while the terminal surface changes visibility and interaction state:

if terminalHasLoaded || selectedSection == .terminal {
    TerminalSurface(isActive: selectedSection == .terminal)
        .opacity(selectedSection == .terminal ? 1 : 0)
        .allowsHitTesting(selectedSection == .terminal)
}

This preserves the representable and its coordinator instead of asking SwiftUI to rebuild them on every sidebar click. The isActive value also gives terminal-specific shortcuts, toolbars, and event monitors an explicit lifecycle. Hidden terminal controls should not continue handling keyboard shortcuts while the user is working in Files or Settings.

Opacity alone, however, is not sufficient for a WebKit-backed terminal.

Preserve the WKWebView object, not necessarily its attachment

On macOS, an embedded WKWebView participates in AppKit focus, drag registration, and window behavior. Keeping it attached but transparent can leave side effects in sections that should have nothing to do with the terminal.

A more reliable arrangement is:

let NSViewRepresentable return a lightweight container;
let its coordinator hold a strong reference to the WKWebView;
attach the web view to the container only while the terminal section is active;
remove it from the hierarchy while inactive, without releasing the object;
attach the same object again when the user returns.

The WebKit object, WebContent process, xterm.js DOM, parser state, and scrollback stay alive even while the view is temporarily detached. The rest of the app no longer has an invisible WebKit view interfering with hit testing or drag sessions.

This is different from serializing terminal text and creating a new renderer. It preserves the renderer itself.

Hand focus back before detaching

Focus is a correctness issue for terminals, not just polish. If the window's first responder remains inside the web view during a section switch, later keystrokes can be delivered somewhere the user cannot see. In the worst case, a stray character is interpreted by the remote shell.

Before detaching an active terminal web view:

Check whether the window's first responder is the web view or one of its descendants.
Explicitly clear or move the first responder.
Remove the web view from its container.
Disable terminal-only keyboard monitors and shortcut controls.

When reattaching, restore focus deliberately after the container is visible. Avoid assuming that SwiftUI's appearance callback and AppKit's responder-chain update happen in the same frame.

Freeze hidden geometry

A hidden but mounted view can still receive geometry changes. If its width follows every animation in the visible section, xterm.js may repeatedly run fit(), and each result may resize the remote PTY.

That creates a subtle class of bugs: opening a file-transfer panel or animating another page changes the dimensions of a terminal the user is not looking at. Full-screen terminal programs then redraw against "ghost" sizes.

Record the terminal's last active width and freeze the inactive container at that width. On reattachment:

align the web view to the visible container once;
let the renderer's resize observer compute the new rows and columns;
send one meaningful PTY resize instead of a frame-by-frame storm.

The same rule applies to side panels: reserve their width only in the section that owns them, not at a shared ancestor that also sizes the hidden terminal.

Keep output flowing without flooding the UI

Detaching the renderer should not pause the SSH transport. Output can continue updating the logical session and renderer while the user visits another section.

High-volume PTY output needs its own boundary. Read callbacks can arrive hundreds of times per second, while sending every chunk through the main thread and WebKit IPC creates unnecessary contention. A practical policy is:

deliver sparse output immediately so typing echo feels instant;
merge continuous bursts into roughly one flush per display frame;
update the bounded recovery buffer before notifying the renderer;
keep session logs on a separate path from visual replay.

The recovery buffer remains useful if WebKit really crashes, but it is no longer the normal navigation mechanism.

Test transitions, not just steady states

The most valuable tests are sequences:

start top, switch to Files, resize the window, and return;
scroll far back, visit Settings, and confirm the same scrollback remains;
focus the terminal, switch sections, type immediately, and verify nothing reaches SSH;
open and close a side panel while the terminal is hidden;
disconnect while hidden, then return and exercise the reconnect path;
close a terminal tab while its web view is detached and confirm observers and script handlers are removed.

These tests cross SwiftUI, AppKit, WebKit, and SSH boundaries. A unit test around one layer will not reveal the ordering failures between them.

The broader rule

View visibility and resource lifetime are not the same thing. A terminal is a long-lived interactive resource with a UI surface, not a disposable page. Once the logical session, transport, renderer, and visible attachment have separate ownership, navigation becomes predictable: switching sections changes what the user sees without quietly rebuilding the tool they were using.

Developer disclosure: I work on Nexus Shell, a native macOS SSH workspace. This article is based on implementation and debugging lessons from that work, not a benchmark against other clients.

Editorial note: This draft was prepared with AI assistance and reviewed against the current SwiftUI, AppKit, WebKit, and SSH implementation before publication.

I tried to vibe code on Windows. It broke me. So I built my own terminal.

Tue, 12 May 2026 23:49:53 +0000

Every AI coding setup I saw online looked the same: Mac, tmux, agents running in split panes, everything humming along perfectly.

I was on Windows. It did not hum.

The tmux wall

tmux is the backbone of serious AI agent workflows. Persistent sessions, split panes, detach and reattach while your agents keep running.

On Windows, native tmux doesn't exist.

Fine — I'll use WSL.

WSL: close enough to break everything

WSL feels like Linux. For about 20 minutes, you think you've solved the problem.

Then the path issues start.

Windows sees: C:\Users\wooyoung\projects\wmux
WSL sees: /mnt/c/Users/wooyoung/projects/wmux

Same folder. Completely different contexts. AI agents write files into WSL. Your Windows-side editor can't find them. Your git is on the Windows side. Your dev server is on the Windows side. Your agent is happily working in a parallel universe.

The worst part: it works — until it doesn't. You're 40 minutes into a session before realizing your agent has been operating in the wrong dimension the entire time.

Port forwarding breaks hot reload. The agent hits localhost:3000, gets nothing, concludes the code is broken, and starts "fixing" code that was never broken.

You end up debugging a WSL networking quirk disguised as a React error.

Multi-agent made it dramatically worse

One agent is manageable. But real vibe coding in 2025 means an orchestrator, subagents, parallel tasks.

My setup: 6 terminal windows, 3 WSL instances, no way to tell which agent was doing what. One agent had gone completely silent — was it done? Crashed? Thinking?

I kept a Notepad file open just to track which terminal was which.

Then one Tuesday evening, I had three agents running in parallel. I wanted to check on one of them. Found it after clicking through four windows. It had been waiting for my input for 45 minutes. The other two had moved on — and built conflicting code against each other.

I closed everything. Went to bed. The next morning I started writing a PRD for Wmux.

What I built

Wmux is a Windows-native AI agent terminal. The problems I kept hitting are treated as first-class design constraints, not edge cases.

No WSL dependency. One filesystem context. No boundary crossings, no silent failures from agents writing to the wrong place.

All agents in one view. Every session visible in a single window. Status, last output, whether it's waiting — at a glance. Ctrl+D to split, Ctrl+N for a new workspace.

Browser automation built in. Claude Code can open a browser, click, fill forms, take screenshots — all via CDP. Not a workaround. A first-class feature.

Notifications that actually work. Output throughput-based detection: when your agent finishes, you get a desktop notification. No more staring at a terminal wondering if it's done.

Session persistence. Close Wmux, reopen it — your sessions are still there, scrollback intact. Like tmux. On Windows.

Why this matters

The corporate world runs Windows. The non-CS engineers I'm trying to get into AI coding run Windows. The developers who are just now discovering multi-agent workflows — a lot of them are on Windows.

The tooling just hasn't caught up. Mac users have cmux. Windows users have... friction.

If you want real multi-agent AI coding on Windows today, you either accept constant pain, or you build the environment yourself.

I chose to build.

v2.2.0 is out. Install in 30 seconds:

irm https://raw.githubusercontent.com/openwong2kim/wmux/main/install.ps1 | iex

Follow the build: github.com/openwong2kim/wmux

Previously: From engineering floor to App Store
Next: I deployed AI to 200 factory engineers. Here's what actually happened.

"Why .NET 9’s CLI is the Glow-up your workflow deserved"

Tue, 05 May 2026 03:26:28 +0000

"From Boring White Text to a Dev Experience That Actually Doesn’t Hurt to Look At".

Let’s be real: for years, the .NET CLI felt like that one reliable but incredibly dull friend. It got the job done, but it had the personality of a spreadsheet. If you’re jumping from .NET 7 or 8, you’re in for a shock. Microsoft finally realized that we spend 90% of our lives staring at a terminal, so they decided to make it look—and feel—like it belongs in 2026.

Here is why you, as a Senior Dev, should actually care about the .NET 9 CLI.

1. The "Visual Soul": Goodbye, Walls of Text

The first thing you’ll notice isn’t a new feature; it’s the Terminal Logger. While it started appearing in .NET 8, in .NET 9 it’s the default, and it is polished.

Progress Bars that actually move: No more guessing if dotnet build is hanging or just thinking.
Clickable Links: Errors now come with direct, clickable links to documentation.
Color-Coded Chaos: Warnings are yellow, errors are red, and successes
are a satisfying green. It sounds minor, but in a massive
microservices build, your eyes will thank you.

Depending on your terminal (like Windows Terminal or Oh My Posh), you’ll see icons for different project types and build stages.

Pro Tip: Use dotnet build --tl (Terminal Logger) explicitly if you’re on a legacy system, but on .NET 9, it’s just there.

2. Automation & "BuildChecks": The Senior’s Safety Net

This is where it gets interesting for those of us managing large codebases. .NET 9 introduces BuildChecks.

Imagine having a linter, but for your .csproj and build logic.

What it does: It analyzes your build process for regressions or "smelly" configurations.
The Command: dotnet build /check
Why it’s useful: It catches things like "Custom task X is slowing
down the build" or "You’re using a deprecated MSBuild property." It’s
basically a code review for your infrastructure.
Git Integration: The CLI is Aware

The .NET 9 CLI is now much more "Git-aware." When you run dotnet new, the SDK automatically detects if you're in a Git repo and can initialize .gitignore files that are actually updated for modern .NET workloads (including stuff for DevContainers and GitHub Actions).

Also, the dotnet workload history command is a lifesaver. If a teammate says, "It works on my machine," you can now check exactly what version of the workloads (MAUI, Aspire, etc.) were installed and when they were updated, making environment parity much easier to debug.

4. Cloud-Native & Docker: The "No-Dockerfile" Revolution

You’re a Senior. You know how to write a Dockerfile. But do you want to?

.NET 9 pushes SDK-based Containerization to the limit. You can now publish a fully optimized, secured, and shrunk Docker image without ever touching a Dockerfile.

dotnet publish /t:PublishContainer -c Release

What’s new here?

Non-root by default: Security is baked in. Images run as a non-privileged user automatically.
Insecure Registries: The CLI now supports pushing to insecure local
registries (great for local K8s testing) without hacking your Docker
config.
Architecture targeting: Easily cross-compile for ARM64 (Graviton/M1) from an x64 machine using just CLI flags.

5. Azure & Aspire: The "Secret Sauce"

If you aren't using .NET Aspire yet, .NET 9 is the sign you were waiting for. The CLI integration with Azure via the azd (Azure Dev CLI) and dotnet aspire commands is seamless.

Smart Provisioning: The CLI can now detect your resource requirements from your code and suggest the right Azure infrastructure.
Deployment: azd up isn't just a gimmick anymore; it uses the .NET 9
SDK to package your apps into container apps with OpenTelemetry
pre-configured.

6. The Advanced "Power User" Commands

For the automation nerds, these are the commands you’ll be scripting into your CI/CD pipelines:

dotnet test --parallel

Now fully integrated with MSBuild for parallel execution across different Target Frameworks (TFM).

dotnet workload sets

Allows you to "lock" a version of the SDK workloads so your whole team stays on the exact same bits.

dotnet tool update

Faster, cleaner, and handles global vs. local tools with better conflict resolution.

What do I think about this?
.NET 9 isn't just about a faster JIT (though it is faster). It's about Developer Joy. The CLI has moved away from being a "black box of text" to a proactive assistant that helps you build, containerize, and deploy without leaving the keyboard.

If you’re still on .NET 7, you’re essentially working in black and white while the rest of us are in 4K. Time to upgrade.

By One Garlos P. 2026

Homebrew: el gestor de paquetes que todo usuario de Mac debería conocer desde el día uno

Tue, 14 Apr 2026 03:27:36 +0000

title: Homebrew: el gestor de paquetes que todo usuario de Mac debería conocer desde el día uno
published: true

tags: spanish, macos, terminal, productivity

Hay una herramienta que debería venir preinstalada en cada Mac que sale de fábrica.

No viene. Y nadie te avisa que existe hasta que llevas meses instalando software de la manera más lenta y tediosa posible.

Se llama Homebrew. Y cuando la descubres tienes exactamente dos reacciones: "esto es increíble" seguido inmediatamente de "¿por qué nadie me dijo esto antes?"

¿Qué es Homebrew?

Es un gestor de paquetes para Mac. En lugar de entrar a un sitio web, descargar el instalador, hacer clic en "siguiente, siguiente, siguiente, aceptar" y arrastrar el ícono a Aplicaciones — todo ese proceso se convierte en esto:

brew install nombre-del-programa

Un comando. El software queda instalado y listo.

Cómo instalarlo

Abre la terminal y copia esto:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Verifica que quedó bien:

brew --version
# Homebrew 4.x.x

Los comandos que vas a usar el 90% del tiempo

# Instalar herramienta de terminal
brew install git

# Instalar app con interfaz gráfica
brew install --cask iterm2

# Actualizar todo
brew update && brew upgrade

# Ver qué tienes instalado
brew list

# Desinstalar
brew uninstall nombre-del-paquete

# Limpiar archivos temporales
brew cleanup

El tip que cambia todo — Brewfile

# Guarda toda tu lista de paquetes
brew bundle dump

# En un Mac nuevo, instala todo de una vez
brew bundle install

Configuras un Mac nuevo en 10 minutos en lugar de un día entero. Eso solo ya justifica instalarlo hoy.

Artículo completo con todos los detalles, la lista de apps que instalo en cada Mac nuevo y cómo conectar Homebrew con tus dotfiles en CommandCat — contenido tech en español sobre macOS, Linux, productividad y cultura geek.

Writing Bootable USB Drives with dd: Precision Over Convenience

Sun, 01 Feb 2026 17:07:13 +0000

Graphical tools like Rufus or Balena Etcher are convenient and widely used. However, when working in constrained environments, rescue scenarios, or legacy hardware, abstractions can hide critical details.

This article explains how to safely create bootable USB drives using the dd command, focusing on correctness, transparency, and risk mitigation.

A Serious Warning: dd Is Not Forgiving

The dd command writes data byte-for-byte to a target device. A single mistake in the output path can irreversibly destroy your primary disk.

Before proceeding:

Disconnect unnecessary storage devices
Identify the correct USB device twice
Never guess the device path

Step-by-Step: ISO to Bootable USB

1. Identify the USB device

lsblk

Look for removable devices (RM=1).

Confirm using:

dmesg | tail -20

2. Unmount existing partitions

sudo umount /dev/sdX* 2>/dev/null || true

3. Write the ISO using dd

sudo dd if=debian-13.3.0-amd64-netinst.iso \
        of=/dev/sdX \
        bs=4M \
        status=progress \
        conv=fdatasync \
        oflag=direct

Key options explained:

bs=4M: improves throughput
status=progress: shows real-time progress
conv=fdatasync: ensures physical writes
oflag=direct: bypasses page cache

4. Validate the result (optional but useful)

sudo fdisk -l /dev/sdX

For deeper inspection:

sudo dd if=/dev/sdX bs=512 count=1 | hexdump -C | head -1

5. Safely eject

sync
sudo eject /dev/sdX

Why dd Instead of GUI Tools?

dd excels when:

Running in headless or server environments
Automating workflows
Debugging boot failures
You need full visibility into the write process

Common Mistakes and Prevention

Mistake	Consequence	Prevention
Using `/dev/sdX1` instead of `/dev/sdX`	Non-bootable USB	Always target the raw device
Forgetting sudo	Permission denied	dd requires block-level access
Omitting fdatasync	Incomplete writes	Always include it
Writing to `/dev/sda` by mistake	Total data loss	Verify with lsblk and dmesg

A Safer Wrapper Script

#!/bin/bash
ISO="$1"
DEVICE="$2"

if [ $# -ne 2 ] || [ ! -f "$ISO" ] || [ ! -b "$DEVICE" ]; then
  echo "Usage: $0 <file.iso> <device>"
  lsblk -d -o NAME,SIZE,MODEL
  exit 1
fi

echo "WARNING: This will overwrite $DEVICE"
read -p "Type YES to continue: " CONFIRM

[ "$CONFIRM" = "YES" ] || exit 1

sudo dd if="$ISO" of="$DEVICE" bs=4M status=progress conv=fdatasync oflag=direct
sync

Conclusion

dd is not just a command — it is a reminder that low-level control comes with responsibility.

When used correctly, it offers unmatched reliability and transparency, especially in real-world Linux scenarios where graphical tools fall short.

Use it carefully, verify everything twice, and it will never let you down.

Debian:

https://www.debian.org/releases/stable/amd64/

GNU dd:

https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html

Arch Wiki (dd):

https://wiki.archlinux.org/title/Dd

Send emails from the terminal using pop

Mon, 22 Dec 2025 07:27:15 +0000

Multi-Account Email Sender (pop wrapper)

This script wraps Charm's pop to send emails from multiple accounts directly from your terminal without config edits. Select your email, then use pop's interactive UI or CLI flags.

Features

Switch between multiple SMTP accounts via gum (or fallback menu)
Secure secrets from ~/.zsh_secrets
Exports POP_SMTP_USERNAME, POP_SMTP_PASSWORD, POP_FROM automatically
Passes all pop args through
Shellcheck clean, bash-compatible

Environment Variables

In ~/.zshrc (non-sensitive):

export POP_SMTP_HOST="smtp.gmail.com" # or smtp.outlook.com, etc.
export POP_SMTP_PORT=587

In ~/.zsh_secrets (chmod 600, gitignore!):

export POP_SMTP_USERNAME1="*Emails are not allowed*"
export POP_SMTP_PASSWORD1="abcd efgh ijkl mnop" # Gmail/Outlook APP PASSWORD
export POP_SMTP_USERNAME2="*Emails are not allowed*"
export POP_SMTP_PASSWORD2="ijkl mnop qrst uvwx" # APP PASSWORD (16 chars, no spaces)

⚠️ POP_SMTP_PASSWORDs are app-specific passwords (not your regular login)—generate from Gmail/Outlook 2FA security settings.

Dependencies

pop (Charm)
gum (optional, menu fallback built-in)

Usage

chmod +x ~/.local/bin/send_email
send_email # Interactive pop
send_email --to *Emails are not allowed* --subject "Hi" --body "Test"

Here is the link to the gist https://gist.github.com/Vaishnav-Sabari-Girish/51cbfc493fee25c209c39f0e74a17103

Save your dotfiles workflow!