Tiny detour from terminal land today as I just shipped the first real release of a sister product: JPtheCat, a macOS menu-bar app that watches what your coding agents are spending and turns it into something a human can actually glance at.

Subscribe now

Yeah, that’s it. Super small utility but something that I cannot possibly live without. You can see me using it while I’m writing this post!

It simple counts your agent tokens so you can keep track of spend. Why? Because token intelligence is literally dollars and cents and if you can master your spend then you end up saving money.

And that’s what I’m trying to do.

The slightly longer version of this is that JPtheCat shows Claude Code spend and Codex rate-limit usage on your Mac, locally, without trying to become a giant dashboard, a cloud billing suite, or another dark panel full of mystery numbers. It is warm, small, opinionated, and yes, it meows.

And it’s the literal sound of my cat, JP. She’s so cute (and spicy).

Why I Built This

Agentic coding has a funny visibility problem.

The work feels magical right up until the bill arrives, or the rate-limit window closes, or a session that felt harmless quietly turns into a surprisingly expensive little adventure. Token counts are useful if you are a machine.

They are less useful if you are a person trying to decide whether to keep going, pause, switch models, or stop asking your agent to rewrite the same function for the seventh time.

Ask me how I know that…

I wanted something that behaved like an instrument, not a report. A small native meter. A menu-bar readout. Something that makes the cost of the current day feel visible without making the whole computer feel like an accounting department.

That is my cat. Or, rather, the digital incarnation of her now.

What JP Does Today

JP the Cat currently tracks Claude Code and Codex.

For Claude Code, it reads the local session data your tool already writes, deduplicates the streamed usage records, handles cache-write pricing correctly, and turns the result into real dollars.

That last part matters. Some usage tools show token counts or rough estimates. JP leads with the number you actually care about: What this is costing you to tokenmaxx to your heart’s content.

For Codex, JP reads local rollout usage and shows the official rate-limit percentages exposed by the tool: The 5-hour window and the weekly window. If a number is official, JP says so. If a future provider needs an estimate, it should be labeled as an estimate.

No provider pretending. No fake confidence.

There is also a 62-provider catalog behind the app, but only Claude Code and Codex are live today. I’m going to work on those after I get the first round of feedback.

The Cat Part Is Not Incidental

JP is not just a logo slapped on top of a spreadsheet.

The app is intentionally light. The website is warm. The menu-bar pill is readable. The dashboard has named light and dark themes. There is a packaged meow. LOL. I had way too fun trying to get a sound capture of her talking.

She is our tiny mascot with very strong opinions about your token burn. Silly, but, not entirely unserious. I mean, money burn is serious stuff.

One thing I keep learning from YEN is that developer tools do not have to feel like punishment. A tool can be local-first, privacy-conscious, technically careful, and still have a little personality.

You see, a terminal can have sounds. A usage meter can have a cat. An installer can be pleasant. These things are not separate from quality. They are part of whether people enjoy using the thing every day.

JP is built from that same instinct. Naturally, cause it’s the same engineer.

v1.0 released yesterday and ships as a notarized macOS app for macOS 14 and newer, with Sparkle updates, a working download endpoint, a 7-day trial, live Stripe checkout, license activation and validation, refund revocation, and a one-time Mac license. The current price is $12.99 for one Mac.

It’s a premium product and one that will only get better with time. No subscriptions. Yay. So much better. You can download the DMG directly from the site, or install it through the public Homebrew tap:

sh
brew tap 8bittts/jpthecat
brew trust 8bittts/jpthecat
brew install --cask jpthecat

There are still plenty of things I want to add: Budget alerts, durable history, export, per-project attribution, more providers, and a deeper paid story after the first release. But the current shape is useful now. It answers the first question cleanly:

What are my coding agents costing me today?

Finally, why post this here? Well, because I can.

But on a more serious note, YEN is about making the terminal feel like a real workbench. JPtheCat is about making the agent layer around that workbench more legible. They are definitely separate products (although integration did come to mind) but fundamentally they come from the same philosophy: Local-first where possible, native where it matters, honest about what is shipped, and allergic to pretending the cloud has to be involved in everything.

Small tools. Clear instruments. Less mystery. More control.

Also, occasionally, a cat.

I’d love for you to give it a try. If you send some feedback I’ll send you a coupon. 100% lifetime key for the first few folks. LMK.

— 8

I use Git all day, but most Git UI still makes me switch modes. And that annoys me a bit because I don’t like things that are slow or that require me to lose context and focus on my present work.

Subscribe now

You see, sometimes I want the full thing fast: Staging hunks, rewriting history, checking branches, reviewing commits, handling stash state. For that, YEN already bundles lazygit. And yes, it’s mature, fast, and good enough that rebuilding it from scratch would be a waste.

But there is another Git moment that happens constantly: I just want to know what changed in the split I am already looking at.

That is what the new native Git drawer is for.

It really is that simple. And useful. And unobtrusive.

It ships in YEN v1.095 as a read-only macOS drawer on Cmd + Shift + G. It opens from the bottom of the active terminal window, looks at the focused split, resolves the local Git working tree, and shows the raw local changes without launching a new shell.

Why I Built It

YEN is becoming a terminal-first IDE, but I do not want every feature to become a second-rate clone of a mature developer tool.

The rule I keep coming back to is simple: vendor what is already excellent, build native surfaces where the terminal/window context makes the workflow better.

Git is a perfect example.

lazygit is the right answer when I want to operate on a repository. It is the full TUI. It can stage, commit, stash, branch, rebase, and move around a repo with intent.

The Git drawer is not trying to replace that.

The drawer is the glance path. It answers:

• What branch is this split on?

• Is this worktree clean?

• What files changed?

• Which changes are staged, unstaged, untracked, or conflicted?

• What does the raw diff look like?

• Can I copy the path, copy the diff, open the file, or jump into lazygit if this needs a real Git operation?

That is a different job than a Git TUI, so it deserves a different shape.

How It Works

Simple. When you press Cmd + Shift + G, YEN opens an attached bottom drawer inside the current terminal window.

It does not create a Quick Terminal. It does not paste a command. It does not spawn an interactive shell. It uses the focused terminal split’s trusted working directory, resolves the repository root, and asks Git for structured read-only data.

The first version shows:

• Branch name.

• Upstream tracking ref.

• Ahead and behind counts.

• Clean or dirty summary.

• Total changed-file count.

• Repo-wide additions and deletions.

• Read-only stash count.

• Grouped file changes for staged, unstaged, untracked, and conflicted files.

• Per-file status badges such as M, A, D, R, U, and ??.

• Per-file additions and deletions, with honest placeholders for binary and submodule rows.

• Raw unified diff for the selected file.

You know, the basics.

The default renderer is intentionally plain. I did not route this through delta for v1 because I wanted the drawer to prove the raw Git path first. Pretty diff rendering can come later. The baseline should be correct before it is decorative.

Read-Only On Purpose

The drawer does not stage files. It does not unstage files. It does not commit. It does not apply stash state. It does not revert files.

And all of that is deliberate.

The feature is meant to be safe to open while cycling through terminal splits. If I am jumping between server, client, tests, docs, and a scratch repo, I want Cmd + Shift + G to be a fast inspection surface, not a place where an accidental keypress mutates history.

When I need to do Git work, the drawer has a handoff button to open the current repo in bundled lazygit. That keeps the roles clean: native drawer for context, TUI for operations.

Failure States Matter

One of the easiest ways for a developer tool to feel sloppy is to confuse “nothing changed” with “I could not read anything.”

So the drawer now has explicit notices for the failure modes I care about:

• No Git repository here.

• Bare repositories are not supported.

• Git is not available at /usr/bin/git.

• Git is taking too long.

• Unable to read this worktree.

• Read-only drawer blocked a mutating command.

• Unable to open Git drawer.

The no-repository case tells you to open a split inside a Git checkout or run git init. Bare repositories point you toward a working-tree checkout. Missing Git points at /usr/bin/git. Timeout and command-failure states suggest refresh, lazygit, permissions, hooks, or Git config depending on what happened.

A clean repository is different. A clean repo still gets the full header and says the working tree is clean. That distinction matters because “clean” is a successful state, not an empty fallback.

Why This Belongs in the Terminal (and YEN)

Most terminals know almost nothing about the work happening inside them.

YEN already has more context: Splits, tabs, trusted working directories, window ownership, local IDE commands, file browser state, PR review surfaces, merge-conflict surfaces, bundled tools, and macOS-native panels.

That makes a native Git drawer useful in a way a generic app-level Git sidebar is not.

The feature is small, but the context is the point. And it’s clearly very intentional. The terminal already knows which split I am working in. The Git UI should use that knowledge.

Now, I could follow-on with hunk navigation, copy, diff rendering, but, I’ll leave those until I actually find myself wanting them badly.

This narrow implementation gets me precisely where I want to go. I hope you find it useful too! I want the read-only foundation to be boringly reliable first: Open the drawer, see the local truth, copy or open what you need, and keep moving.

That is the kind of terminal-first IDE feature I want YEN to have more of. Not a giant replacement for every tool you already trust. A small native surface that removes one more context switch.

Simple. Elegant. Useful.

— 8

This work ships in YEN v1.087.

I spent time on something that can sound small from the outside: Normalizing the design in the Settings Panel.

Subscribe now

That means labels, sliders, descriptions, shortcut rows, color controls, and the little bits of spacing that most people only notice when they are wrong. It is not the kind of thing that shows up well in a feature checklist. It is also exactly the kind of thing that changes whether an app feels cared for.

But I really think this stuff matters, especially because I use this small device every single day for really serious work.

You see, the Settings (as we all know) is where a user goes when the default product does not quite match how they work. If that surface feels uneven, the message is subtle but real: customization exists, but it is not loved. I want YEN to send the opposite message.

If I give you knobs, those knobs should feel deliberate. Intentional.

Cared for, even.

The Small Things, Always

The Settings panel had grown quickly because YEN has a lot more native configuration now.

There are terminal basics like font, cursor, opacity, padding, and background images. There are notification controls. There are workspace controls for the tab sidebar, scratchpad, and browser behavior. There is the theme gallery. There is a full keyboard shortcut editor with conflict detection. There are chromatic window borders with focused and unfocused palettes.

Individually, these features worked. Together, the page was starting to show seams.

Some labels wrapped into two lines while nearby labels stayed on one line. Some sections had helpful little descriptions under the heading, while others jumped straight into controls.

Some sliders had values on the far right, but did not give you a direct way to type a value. Padding sliders had visual marks that made the control look busier than it needed to be. Border width and border radius could both read as 1 px, but their slider positions did not feel like they shared the same baseline.

None of that is catastrophic. But all of it adds up. And it hurts my face when I see things that aren’t where they should be.

Or as pretty.

A settings panel should not make you wonder whether two controls are built from two different design systems. It should feel like one surface.

What I Changed

I normalized the row-label column across the Settings tabs.

That is a simple sentence, but it matters. Labels now get the same amount of room in General, Sounds, Workspace, Themes, and Keyboard. A control like Window Border should not be forced into a cramped two-line label while nearby controls have space. The visual rhythm should stay stable as you move through the app.

I also made section descriptions canonical.

YEN already had a few nice section headers with short explanations, like the Browser section in Workspace. I expanded that pattern across the panel. General now explains what Font, Cursor, Behavior, and Appearance are for. Sounds explains focused notification behavior and Translate-on-Dictate. Themes explains catalog scope and gallery previewing. Keyboard categories explain what kind of shortcuts live in each group.

These descriptions are intentionally short. They are not tutorials. They are orientation. The goal is to make the panel easier to scan without turning every section into documentation.

I brought manual numeric entry back to slider-backed controls.

Sliders are good for feel. Text fields are good for precision. Settings needs both.

Padding X and Y now keep the slider, but also let you type the pixel value directly beside the control. Window Border width and radius now work the same way. The value is no longer just a readout; it is editable.

That sounds minor until you are trying to set two values to exactly the same number. A slider is great when you are exploring. It is annoying when you already know the value you want.

I also fixed the baseline mismatch between Window Border width and radius.

Both can show 1 px, so both should treat 1 px as the same kind of minimum. Before this pass, the radius slider could sit at a different baseline than width even when both read as 1 px. That is the kind of mismatch that makes a panel feel slightly off even if you cannot immediately name why.

I checked the focused and unfocused outline color behavior too.

The Window Border controls let you pick a focused palette and an unfocused palette, or let the border match the active terminal theme. That surface only earns its keep if the colors actually resolve, persist, preview, and change independently. I tightened the review around those code paths and kept the existing contrast and theme-resolution behavior intact.

Oh, and at least for my own work on the design, I also added test coverage for saving multiple custom keyboard shortcut combinations. I don’t want to go backwards, ever.

The Keyboard tab is not just a visual list. It writes real keybind overrides. A shortcut remap has to unbind the old default trigger and bind the new one so both do not stay active in parallel. This pass added coverage for multiple remaps saving together, including combinations that use Option, Shift, Control, and Command.

That is the difference between a settings UI that looks editable and one that can be trusted.

Why This Is Worth Doing

I like building big features. Browser previews, speech-to-text, command palettes, file browsing, chromatic borders, and terminal-first IDE tools are fun because they are obvious. But software quality is often decided by the less obvious work.

Does the value field clear correctly when you start typing a new number? Does a label wrap because the row was designed too narrowly? Does a section tell you what it is for without talking too much? Does a slider show the same value in two places but behave differently under your hand? Does a shortcut editor really save the combination you recorded?

Those are not superficial details to the person using the app every day. They are friction.

And because YEN is a terminal-first IDE, the bar is higher. Developers live in tools for hours. They notice inconsistency. They notice when a native panel feels like a quick wrapper around a config file instead of a real product surface.

My approach is to keep the terminal powerful while making the native UI feel intentional wherever native UI is the better tool.

Settings is one of those places.

What I Want Settings To Communicate

The Settings panel should say: This app is configurable, but not careless.

It should say that visual customization is not an afterthought. It should say that accessibility and focus states matter. It should say that keyboard shortcuts are first-class, not a hidden text-file trick. It should say that if something has a slider, you can still type the value like an adult.

Most of all, it should say that I am willing to improve the boring parts.

There is a lot of quiet, methodical work in YEN. Some of it is deep architecture. Some of it is release safety. Some of it is making sure a label does not wrap awkwardly next to a toggle.

I think all of it counts.

The terminal is the center of the product, but the surrounding surfaces are part of the experience too. If those surfaces feel uneven, the product feels uneven. So I keep going back through them, tightening the details, and making the app feel more like itself.

That is what this Settings pass was about.

Not a redesign for the sake of a screenshot.

A normalization pass so the whole panel feels more coherent, more precise, and more respectful of the person using it.

Obsessing about the product to even the smallest pixel is how you know you really care and is a good sniff test of quality.

That’s the bar. I’m going to keep reaching for it.

And this makes me really, really happy.

— 8

YEN has always had two halves in the name. The terminal half is the part you can see — the app, the IDE, the splits, the tabs, the file browser. The musical half has been quieter and never mentioned.

Well, until now.

Subscribe now

I just shipped Terminals and Tunes — an AI-assisted music label that produces background music for the kind of person who reads my blog. Late-night coders, deep-focus readers, anxiety-relief sleepers, meditation-curious focus types, cottagecore journal-keepers. '

Five personas. Same channel. Same person behind it. Different worlds.

This post is about why I built it, what’s live right now, and how the pipeline actually works.

Why Music?

The terminal-first IDE thesis I’ve been writing about for two years is “the developer surface should be the terminal.” Background music is the same kind of surface. It’s the thing playing in the corner while you work — quiet, dependable, doesn’t need attention, doesn’t sell you something every thirty seconds.

The Lofi Girl channel earns reportedly six figures a month doing exactly this, with one persona and a finite catalog. The category is real. The audience is real. The competitive moat is taste plus volume plus distribution discipline — all things I can build with CLI tools.

So I built one to see if it would really work.

It kind of does.

The 5 Personas

I picked five niches I think pair well with the YEN: Terminals and Tunes brand and don’t overlap with the giants:

1. YEN Terminal Tunes — synthwave for late-night coding. Restrained, melodic, low-distraction. Background music for the terminal.

2. Idle Coast — bossa nova / lounge / chillhop. For cafes, slow afternoons, and golden-hour workspaces.

3. Noise Floor — brown noise plus soft ambient pads. For sleep and deep relaxation.

4. Gamma Daemon — binaural focus / 40Hz gamma. For study sessions, deep focus, and meditation.

5. Hearth 16 — cottagecore acoustic folk plus nature ambience. For reading, journaling, and quiet evenings.

Each persona has its own anime-themed visual identity, its own audio fingerprint, its own niche audience. They all roll up under one YouTube channel (@yenFTW) and one Spotify For Artists account, so I claim once and pitch all five.

The Pipeline

Every step is CLI or scripted. My role is taste and quality control. The actual work is:

1. Generate — Suno Premier through aimusicapi.ai. I send a prompt; the API returns audio. About $0.10 per track.

2. QC — A TUI I built. I press k to keep, r to reject, p to preview. Hard taste gate. Most tracks get rejected.

3. Mix — ffmpeg crossfade for long-form mixes. Loudness-normalize to -14 LUFS for Spotify.

4. Cover — Higgsfield’s kling3_0 at 4K renders one ten-second seamless loop per persona. Every release cover is a frame extracted from that loop, so the album art always matches the YouTube video’s character, world, and lighting.

5. Video — ffmpeg layers the seamless loop under the audio at 4K. Audio is 320 kbps AAC, video is H.264 high-profile at CRF 16.

6. Metadata — claude -p writes the YouTube title, description with chapter markers, and 15-25 SEO-tuned tags.

7. Hard upload gate — Operator approval required before anything publishes. I review every file. Nothing gets posted on auto-pilot.

8. Upload — YouTube Data API for the video (with containsSyntheticMedia: true because the AI disclosure is mandatory and honest), Supabase Storage for the durable archive, DistroKid for streaming distribution.

The whole thing runs from a slash command: /yen-tunes generates per-persona in parallel, then converges at QC, then fans back out for per-mix cover and video. End-to-end it’s about ninety minutes of operator time and $1-2 in API credits for a single pass across all five personas.

Not too bad.

It’s just an experiment and I’m still messing with the settings and outputs as well as the distribution to other platforms. It’s not perfect but it’s amazing what you can do with a little knowledge (and an agentic harness).

I can’t imagine a world where music isn’t part of my programming “logic” and so I’ve had a blast experimenting and seeing how it all fits together.

I hope you enjoy.

— 8

If you want to listen, the personas and playlists are here:

A small but impactful change — the type that I like.

Subscribe now

I’ve effectively removed the custom notification sounds and the really fun sound packs that I had originally designed.

Yeah, I know. That probably sounds like a small change. Pun intended. But, that stuff was never headline feature. It is not a big new surface. It is not the kind of thing that gets a splashy screenshot.

But it is one of those product decisions I care about a lot because it says something about what YEN is trying to become.

I want YEN to feel powerful without feeling busy. I want the terminal to pick up the things that help me move faster, and I want it to drop the things that mostly create maintenance weight, settings weight, release weight, and cognitive weight.

Custom audio notifications started as a fun idea. I liked the personality of it. A terminal can be serious and still have taste. It can have little moments of delight. That is why I shipped the original sound work in **Making Your Terminal Sound Like Fun**.

Over time, though, the honest version became clearer. The system was bigger than the value it created.

There were custom imports. There were official downloadable sound packs. There were bundled sound identifiers. There was a manifest. There were checksums. There were signatures. There was release-pipeline logic to package, upload, validate, and prune the audio artifacts. There was Settings UI for downloading and removing packs. There was public documentation that had to explain all of it.

And for what?

Most people need notification sounds to do one job: tell them that something happened. Well, macOS already has system sounds for that. They are familiar, local, accessible, and boring in exactly the right way. If YEN can let me choose None, choose a system sound, control the volume, decide whether banners appear, and decide what happens while the app is focused, then the product need is covered.

Everything beyond that has to earn its cost.

The sound packs stopped earning it. So, a few versions ago, I killed it. Now, notification sounds are just system-only. The current model is simple:

• None means silence.

• System sounds come from macOS.

• General and Build notification streams keep their own routing.

• Each stream still has delivery mode, volume, and focused-window behavior.

• Old custom or bundled sound selections load safely and fall back to silence.

The old audio files are not deleted from anyone’s Mac. YEN just stops scanning them, surfacing them, or depending on them. That part matters.

I do not want cleanup work to punish existing users. If someone has an old settings export or old app-support files, the next version should load cleanly. The app should not crash. The Settings panel should not show broken rows. The release pipeline should not look for artifacts that no longer exist.

Retirement should be boring. Or, at least in the case of good software.

Ok, So, Why? The Real Reason…

The real reason is not disk space. The real reason is product clarity.

Every feature creates a shadow. The visible part is the button, picker, or setting. The shadow is everything behind it: validation, tests, docs, release automation, support burden, stale copy, edge cases, and the quiet fear that a rarely used path will break during a release.

It’s about focus.

When a feature is central, that shadow is worth it. When a feature is peripheral, the shadow gets expensive.

YEN has already gone through this kind of pruning before. Chat, mail, and calendar were removed from the active product, but I kept the historical engineering packets so they can be understood or restored later without leaving compatibility code in the shipped app.

That is the pattern I want for a great Terminal:

• Remove the runtime surface when it no longer belongs

• Preserve enough history to understand the decision

• Keep old user data safe

• Keep the release pipeline honest

• Keep public documentation aligned with what actually ships

That is different from pretending the feature never existed. It did exist. It taught me things. Some of the notification routing work still matters. The focused-window behavior still matters. Per-service delivery still matters. The Settings shape still matters.

The custom sound library just does not need to be part of the product anymore. Shipping as a solo developer means saying no even after saying yes once. It’s hard because I want to build everything.

But that just doesn’t make sense. Sometimes the best feature work is subtraction.

And in this case, we all just get a better product.

— 8

I’ve shipped three things into YEN over the last stretch that look unrelated on the surface — an agent evidence trail, a real port inspector, and full macOS scriptability. They are not unrelated. They are the same argument made three times.

Subscribe now

The argument is this: A terminal-first IDE is not a text editor with a terminal panel attached. It is the inverse. Start from the terminal and add the IDE capabilities that make the terminal safer, more contextual, and more trustworthy. Each of these three pieces is what that thesis actually looks like in code.

Here is what shipped, and why each one matters.

If an agent touches your repo then your terminal should have receipts.

The current AI coding market has a trust problem that gets ignored because the demos look productive. A tool opens an agent session, edits files, runs a few commands, and then leaves behind something that feels more like vibes than evidence. You are expected to merge based on the fact that an agent looked busy.

That is not good enough.

YEN now ships yen agents list, yen agents open, yen agents timeline, yen agents note, yen agents export, and yen agents templates as a bounded local-first surface around first-party adapter profiles like claude and codex.

yen agents open launches a session without pretending the adapter is more reliable than it is. If the binary is missing, the flow stays fail-open and drops to a normal shell. But when launch metadata is available, YEN records it: binary path, probe command, probe result, version, launch mode, fallback state, workspace identity, slot, branch, and dirty-state context. “The agent ran” is not one fact. There is a huge difference between “Claude launched normally in the expected workspace” and “the adapter was missing so the session really fell back to a shell.”

yen agents timeline is the readable history surface for that state. Workspace-scoped, source-tagged, filterable. Session events show as agent:<slot>. Human notes are human. Supervisor-style notes are **supervisor**. Internal events are system. Output renders as text or JSON, with stable schema metadata so downstream consumers don’t reverse-engineer a second unofficial contract.

The important part is not the filter set. The important part is that the timeline doesn’t stop at “agent opened” and “agent closed.” It also carries the latest linked IDE evidence that already exists elsewhere in YEN — local verify and test results, quality and workflow reports, merge-readiness snapshots, PR-review evidence, current-branch CI state, and the local build-watch snapshot — through one shared evidence model.

Status is explicit. The timeline and export surfaces share an evidenceStatus vocabulary: missing-report when the artifact does not exist, stale-report when it exists but is too old to trust, unverified when no meaningful proof exists yet, and exported-with-gaps when I can still produce a bundle but the bundle itself tells you what is missing instead of pretending completeness.

yen agents note is the missing human layer. Notes support lightweight templates for review approval, review rejection, handoff for review, and handoff for merge. They can validate that a note is actually bound to the right session or slot, so a human approval becomes a recorded part of the handoff instead of a sentence someone remembers writing in Slack ten minutes earlier.

yen agents export turns the local session history into a handoff bundle in Markdown or JSON: timeline, approvals, handoffs, workspace-keyed repo context, risk summary, adapter metadata, explicit evidence gaps, linked IDE evidence references. It does not invent a second review namespace — it reuses the same truth YEN already uses for verification, workflow, merge-readiness, and PR review.

The whole surface stays local-first. Artifacts are local. Timeline is local. Notes are local. Export is local. Archive is opt-in. Retention is short by default at 7 days. Redaction happens before saved artifacts are written. And if the capture path breaks, YEN fails open and preserves the terminal session rather than pretending the evidence story is stronger than it is.

That is what I mean by receipts.

Your terminal should know what’s running on every port.

You are running Next.js on port 3000. Django on 8000. Postgres in Docker on 5432. Then something mysterious claims port 5000 and you have no idea what it is.

The usual answer is some combination of lsof, ps, and docker ps run separately, parsed manually, and forgotten immediately. Maybe you install a third-party tool that needs Node 18+ just to show you a table.

YEN already had yen ide ports as a basic lsof dump. Now it is a full port inspection surface:

bash
yen ide ports              # Dev ports with framework detection
yen ide ports --all        # Everything, including system services
yen ide ports 3000         # Deep dive on one port + optional kill
yen ide ports ps           # All dev processes with CPU / memory
yen ide ports clean        # Find and kill orphaned / zombie processes
yen ide ports watch        # Live monitor, 2-second polling

Every subcommand supports --json for scripting and --yes to skip confirmation prompts. The default view is dev-focused — system services like ControlCenter and rapportd get filtered out unless you pass --all.

Framework detection runs in three tiers. First, process name and command-line pattern matching — python3 manage.py runserver is Django, bun run next dev is Next.js running on Bun. Twenty-plus frameworks covered: Next.js, Vite, Django, Flask, Uvicorn, Gunicorn, Rails, Spring, Supabase, Turso, Caddy, Traefik, Zig, Rust, Go, PHP, Deno, Bun, Node, Java, Ruby. Second, working-directory inspection — resolve each process’s cwd via lsof, walk up to find the project root by looking for package.json, go.mod, Cargo.toml, or pyproject.toml, then check for framework config files. Third, Docker container mapping — cross-reference docker ps to pull container names so Postgres, Redis, and nginx get named correctly instead of showing up as a mysterious docker-proxy process.

The result actually tells you what is going on:

COMMAND     PID      PORT     FRAMEWORK   UPTIME   CONTAINER   BIND
node        41023    3000     Next.js     2h 14m   —           *:3000
python3     41156    8000     Django      1h 03m   —           127.0.0.1:8000
docker-pr   41289    5432     PostgreSQL  4h 31m   myapp-db    *:5432
bun         41302    3100     Vite        22m 08s  —           *:3100

yen ide ports 3000 shows everything about the process on that port — PID, user, CPU, memory, working directory, project root, git branch — then asks if you want to kill it. SIGTERM first, not SIGKILL, with a 2-second wait. Every kill gets logged to YEN’s IDE timeline because a terminal-first IDE should keep receipts on destructive actions.

yen ide ports clean finds two kinds of problems: orphaned dev servers whose parent died and got reparented to PID 1, intersected with a dev-process allowlist so we don’t flag system daemons like httpd or cupsd as false positives; and zombie processes still holding a port. Both get listed with reasons, and you can batch-kill them with one confirmation prompt.

yen ide ports watch polls every 2 seconds and reports opened and closed ports with timestamps, with trap cleanup on Ctrl + C, SIGTERM, or SIGHUP so the temp file doesn’t leak.

About 1,300 lines of bash and Python, 8 regression tests, no new dependencies — just lsof, ps, and docker stitched together into one terminal-native view.

Your terminal should be scriptable.

Most terminals are black boxes. You launch them. Maybe you pass a command. That’s it.

The problem is that developers have workflows — not commands. “Open this project” means: navigate to the repo, split the window, start the test runner on the right, start the dev server on the left. Doing that manually every time is fine once. It’s friction at scale.

The standard answer in the macOS world is AppleScript. Terminals have historically been bad at it because they are fundamentally interactive processes — you can open a window, but can you address a specific surface? Can you tell a pane what to run?

YEN has a solution for this now. It ships a branded .sdef. Open Script Editor, find YEN.app in the Library, and browse the dictionary. The current surface is deliberate and minimal:

- new window — opens a terminal window
- new tab — opens a tab in the frontmost window
- split — splits the active surface
- surface configuration — lets you configure an individual surface
- Terminal objects have `pid` and `tty` properties

YEN-native features — layout presets, scratchpad, tab sidebar, the PR review workspace — are not exposed through AppleScript `perform action`. The `Cmd + Option + 1-0` layout presets are intentionally not cloned into a second layout source of truth. Compose three-column layouts with `new tab` + `split` calls rather than replicating preset logic externally.

The App Intents surface shares the same canonical action-string catalog as AppleScript, so Shortcuts.app, Focus Filters, and Siri Shortcuts compose with the same YEN actions.

Why these three belong together.

Each of these surfaces is a different cut at the same idea.

Agent receipts say: If a session changed the repo, the terminal should be able to answer “what exactly happened?” without asking you to trust a second system. The receipts stay close to the repo, the terminal, and the review flow you are already in.

Port inspection says: if a process is running, the terminal should be able to tell you what it is, where it lives, and let you kill it safely. With logging. Because a terminal-first IDE should keep receipts on destructive actions, even small ones.

Scriptability says: if your workflow has shape — open the project, split the panes, start the test runner — the terminal should let you encode that shape. Not as a brittle command sequence, but as something macOS Automation can address by surface, by `pid`, by `tty`.

In each case, the question is the same. Should this thing live in a separate hosted dashboard, a third-party CLI, or a JavaScript wrapper? Or should it live in the terminal you are already in?

I keep landing on the second answer. The terminal is where commands actually run, where repo state is visible, where output becomes real, where agents either prove their work or don’t. If that is true, then trust, observability, and scriptability belong there too — not bolted on, not in a browser tab, not behind a hosted account.

That is the bet. Not bigger spectacle. Better receipts.

— 8

I added a browser preview to YEN. That sentence can sound bigger than it is, so I want to be precise about it. YEN is not becoming a browser. It is not shipping Chromium. It is not turning into Electron. Eww.

Subscribe now

It is not trying to replace Safari, Arc, Chrome, Firefox, or whatever else you already use for the open web. What I shipped is much narrower and much more useful for the kind of product YEN is trying to be:

A native WebKit preview surface, launched from the command palette or yen web, for docs, HTTPS pages, and local development servers.

It is a standard window by default, with an explicit split when you ask for one. Yay.

Why Does a Terminal Need This?

I keep coming back to the same idea with YEN: The terminal-first IDE is not a text editor with a terminal panel attached. It is the reverse. Start from the terminal, then add the pieces that make terminal work more direct, more trustworthy, and less scattered.

A browser preview fits that idea, but only if it stays disciplined. Developers constantly bounce between the terminal and the browser:

• Documentation.

• Localhost servers.

• Preview pages.

• Generated docs.

• Release notes.

• Internal references.

That context switch is not always bad. The full browser is the right place for most browsing. But there is a class of terminal-adjacent web content where leaving the terminal flow feels heavier than the task deserves.

I do not want to open a whole browser tab just to check a local docs page. I do not want an embedded browser engine bundled into the terminal just because a preview window is useful. I do not want terminal links silently captured before the behavior has earned trust.

So the starting point is deliberately small: Open Cmd + Shift + P, type Browser, press Enter. Done and done.

From there, you can type an HTTPS URL, open a localhost or loopback development server, go back, go forward, reload, stop loading, or hand the current page to your default browser.

If you use yen web open, the command goes through the same policy. If you choose Browser Split or yen web open --split, YEN mounts the same preview beside the terminal in an app-owned split. That is it. That is the point.

Native First, not Browser-Engine First.

The easy way to add a browser-shaped feature is to ship a browser engine. That is also the expensive way.

Chromium-class runtimes bring subprocesses, GPU behavior, sandboxing complexity, packaging weight, security update pressure, and a huge amount of product gravity. Once you carry that runtime, the feature stops feeling like a preview window and starts pulling the whole app toward becoming a browser shell.

That is not YEN.

YEN already has a hard native-first rule: Before adding a dependency or vendored binary, check whether macOS already provides the right API. For this feature, macOS does. The preview uses Apple’s WebKit stack:

• WKWebView

• WKWebViewConfiguration

• WKNavigationDelegate

• WKUIDelegate

• WKWebsiteDataStore.nonPersistent

• NSWorkspace.open

That is the right shape for a Mac app. It keeps the feature small, native, reversible, and understandable. It also keeps the terminal engine out of the story. No Metal renderer changes. No swap-chain changes. No renderer-owned terminal-pane integration. No default-on hyperlink interception. No production data changes. No release artifact format changes. No vendored browser runtime.

Nothing that will get in the way or bloat the app.

The default browser preview is an app-owned utility window. The optional split is app-owned too. Neither one is a new foundation for the terminal engine.

The Trust Boundary is the URL Field

The interesting part of this feature is not the toolbar. The interesting part is the policy.

If I put a web view inside a terminal, I need to be clear about what it is allowed to open.

The current rule is simple: HTTPS pages can load. Loopback HTTP can load.

But external schemes like mailto: and tel: get handed off to macOS from explicit top-level opens. Unsafe or surprising schemes get blocked.

And, of course, it’s private by default.

The shipped browser uses a non-persistent WebKit data store.

That means YEN is not trying to become your browser profile. It is not importing Safari cookies. It is not keeping a long-lived browsing history. It is not turning a preview window into another place where state silently accumulates.

That choice is partly about privacy. It is also about reversibility.

If a future expansion does not earn its place, I want to remove that expansion without leaving a weird pile of browser state behind.

That is one of the standards I keep trying to apply across YEN: New surfaces should stay easy to revert until they prove they belong.

Persistent browsing state might make sense later for a specific workflow. If it does, I want that to be a deliberate decision with a clear storage policy, a clear user control, and a clear rollback path.

For now, non-persistent is the right default.

How and Why Does This Fit for YEN?

The terminal is already where the work starts. You run the dev server there. You see the port there. You read the failing command there. You open the command palette there. You jump into docs there.

Cool.

The browser preview is useful because it respects that center of gravity. It gives YEN a small native window or explicit split for web context without asking the terminal to become a browser, and without asking the browser to become the IDE.

YEN should absorb useful developer workflow pieces only when they make terminal work feel more coherent. The file browser made sense because navigating files is part of terminal work.

The command palette made sense because discovery is part of terminal work. The IDE workflows made sense because trust, verification, review, and project context are part of terminal work. The browser preview makes sense only if it stays in that same category: A focused preview for terminal-adjacent web context.

Not the open web as a lifestyle. Not browser automation. Not a Chromium distribution in disguise. Just a small native bridge between the terminal and the pages developers actually need while working.

The best part is how little had to change. The core browser code lives in one isolated macOS feature folder. The command palette has two browser actions: Browser and Browser Split. The CLI and Settings integrations are narrow. The URL policy is a pure testable layer. The WebKit configuration is created up front.

The external handoff path checks whether macOS accepted the URL instead of pretending every handoff worked. That is the shape I want more YEN features to have.

Small surface. Clear policy. Native API. Easy rollback. Tests around the weird edges.

The Bigger Point

I think terminal products keep getting pulled in two directions.

One direction says the terminal should stay dumb forever. The other says the terminal should become a browser-shaped AI workspace with a shell somewhere inside it.

I do not like either answer.

The terminal should get smarter, but it should get smarter in a terminal-native way. That means native surfaces where native surfaces make sense. Local-first state where local-first state makes sense.

Explicit trust boundaries. No surprise capture. No giant runtime unless it truly earns its cost. No feature expansion without a keep-or-revert checkpoint. The browser preview is a small example of that philosophy.

It is not the centerpiece of YEN. It is not a pivot. It is just a useful native surface that lets the terminal-first workflow breathe a little more easily.

And sometimes that is exactly the kind of feature a product needs.

— 8

I just removed three whole product surfaces from YEN:

1. Chat

2. Mail

3. Calendar

This makes me a bit sad but it was as important of an update as many others in the last few months. Focus is a feature and it’s hard to do.

Subscribe now

This is, of course, not the usual kind of release story. Most product writing is about what got added. This one is about what I decided not to keep carrying.

I think that matters, because one of the easiest ways to make a product worse is to confuse activity with progress. Shipping more things is easy to celebrate. Carrying more things forever is the part that gets expensive.

And it’s really easy to add features these days which means that the most important decisions is what you decide to not build and ship.

You see, for a while, YEN had a broader shape. It was not just a terminal-first IDE. It also had a community chat surface, a mail client, and a calendar client living inside the same product. At one level, that was interesting. It proved that the terminal could hold more of a working environment than people usually assume.

But there is a point where an interesting proof stops being the right product.

The point is that I do not want YEN to become one more app that keeps every experiment alive because removing it would feel like admitting something. I would rather be honest about what is actually central.

The central thing is the terminal-first IDE.

That means:

• Native terminal quality

• Trustworthy local workflows

• File and project navigation

• Build and review tooling

• Command surfaces that make terminal work faster without making it feel fake

Chat, mail, and calendar were not strengthening that center anymore. They were competing with it. And, to be honest, not many folks were using them but that’s also because we’re still pretty small (and growing).

The deeper problem is surface area. A product feature is not just a button or a command. It is an ongoing obligation. Chat meant backend tables, storage rules, attachment handling, proxy paths, privacy assumptions, moderation-adjacent questions, cleanup rules, and public documentation that had to stay true.

Mail and calendar meant OAuth flows, keychain assumptions, callback routes, local state contracts, desktop integration residue, notification semantics, legal/privacy copy, and recovery behavior for systems YEN did not control.

Even when those features are “done,” they are not done. They keep charging rent:

• Engineering attention

• Test coverage

• Release anxiety

• Documentation maintenance

• Privacy and legal review

• Restore-path complexity during unrelated refactors

That is the part people underestimate and certainly not something that anyone non-technical would even think about (although those folks are probably not using YEN).

A small feature that touches auth, network boundaries, notifications, storage, and public docs is not small. It is a permanent tax. No one likes taxes. Taxes suck.

But the the non-obvious gain is trust.

I think product focus is often described too softly, like it is mostly an aesthetic preference. It is not. Focus improves trust. Every feature I remove is one less thing that can silently drift out of sync. One less thing that can break on release day. One less public claim that can become false. One less background system whose edge cases I have to remember when I am changing something that should have been unrelated.

That matters a lot for a terminal-first IDE, because this kind of product only works if people believe the boundaries are legible.

Subtraction is part of honesty. YEN does not get stronger by collecting adjacent ideas forever. It gets stronger by becoming more exact about what it is for.

The best version of YEN is not “the app that also does everything else.” It is the app where the terminal is the center of gravity, the desktop integration feels native, the workflows are trustworthy, and the extra surface area earns its place.

Chat, mail, and calendar stopped earning their place. So I removed them. I think more products should do that.

There is a lot of pressure in software to act like every shipped feature is sacred. I do not buy that. Sometimes the highest-leverage feature is the one you stop shipping. Sometimes the most user-respecting thing you can do is narrow the promise. Sometimes focus is not what remains after product strategy.

Focus is the product strategy. That is what this cleanup was really about.

YEN is better when it is more itself, as it has been and as it should be. Authenticity. Truthfulness. Clarity. Focus. The result? Even greater productivity.

That’s the point.

— 8

Every other Mac app in my life has trained my hands the same way. Cmd + C copies. Cmd + V pastes. If a shortcut needs a paragraph of explanation before it makes sense, the shortcut is probably wrong.

Subscribe now

I ran into exactly that problem in YEN. Ctrl + V could still move clipboard data through the terminal stack, but Cmd + V did not behave like a real Mac app. That sounds small until you remember what YEN is trying to be.

Well, this now works in v1.036.

I have been building YEN around a simple thesis: The terminal-first IDE should feel more like a real desktop app, not less. If I am asking people to live in the terminal for IDE flows and agent work and more, then, I do not get to shrug when one of the most basic desktop behaviors feels off.

So, why doesn’t upstream libghostty do this? Because it’s a terminal emulator while YEN is a terminal -first IDE with path-oriented workflows around Codex, Claude, local tools, and file-aware commands.

And so that’s fine since it’s behaving like any normal, ordinary terminal paste behavior for the kinds of payloads a terminal naturally understands. But, I wanted just a bit more than that.

That is an important distinction. This is not “libghostty forgot paste” or anything funky like that; it’s just that we have a very different product policy.

What Changed and Why This Matters

I fixed the hotkey at the right layer first.

Instead of asking “is this the Cmd + * keystroke shape?” YEN now asks “what menu action did YEN resolve this event to?” If the resolved action is paste: or pasteSelection:, and the relevant clipboard has contents, the surface routes through AppKit the way a native Mac app should.

That matters because it avoids stealing unrelated shortcuts.

If someone remaps a binding or another YEN command happens to share a similar keystroke shape, the bypass stays closed unless the resolved menu action is actually a paste action. That is the difference between a shortcut hack and a native fix.

So, why does this matter? Well, I think a lot of terminal work gets framed as performance, rendering, tabs, themes, or shell integration. All of that matters.

But the terminal-first IDE also has to solve a quieter problem: If I am asking you to live in the terminal for more of your day, the terminal has to stop feeling like the place where desktop behavior goes to die.

That means tiny things matter.

Cmd + V should mean paste. And now it behaves like it should on macOS.

And if the terminal is going to be the IDE, that is the level of care it has to absorb.

— 8

Well… we’ve done it, folks. YEN is officially v1.0! Whoot. 🎉

Subscribe now

I do not use version numbers as marketing confetti, though. I mean, v1.000 — or how I’ve been numbering it — is not me pretending the work is done. It is me saying the thesis is real now. The product I wanted to build is no longer hypothetical. It is in the repo, in the shipped app, in the release harness, in the native macOS surfaces, and in the command surface I use every day.

I use YEN to build YEN, a fun little personal project — built on top of libghostty — that a lot of folks have started to use. For that, I am super grateful.

The Thesis.

Most IDEs are text editors that bolted on a terminal panel. The editor gets the architecture. The terminal gets a rectangle near the bottom of the window. The editor gets search, code intelligence, review, migration, workflow automation, collaboration, and the language about focus and speed. The terminal gets treated like a utility room.

I wanted the opposite.

Because the terminal is where code meets reality. It is where builds fail, services restart, migrations run, diagnostics become useful, containers get launched, review comments turn into actions, and dangerous commands should feel dangerous before you press the “Enter” key.

YEN starts with a fast native terminal on macOS and layers IDE capability around that terminal-first workflow. Keep the core local-first. Use native APIs where they are genuinely better. Stay in the terminal unless a richer native surface is actually justified.

That is the whole product in one paragraph.

What v1.0 Actually Ships.

This is not a terminal with a roadmap attached. It is already a broad terminal-first system. The new IDE layer matters most here.

YEN now ships project detection, trusted environment loading, local LSP lifecycle and diagnostics, AST fallback, universal project search, verification bundles, approval gates for risky commands, workflow execution, PR review tooling, terminal sharing, local devcontainer control, deterministic VS Code inventory and import, and native macOS PR review and merge-conflict workspaces launched from the command palette. That is the point where “terminal-first IDE” stopped being a slogan and became a product characteristic.

But v1.0 is not only an IDE story. It is also a story about making the terminal feel like an environment instead of a blank shell. YEN ships a built-in file browser, command palette, tab sidebar, scratchpad, split layout presets, split labels, screenshot tooling, curated themes, keyboard remapping with conflict detection, managed notification sounds, bundled CLI tools, weather, and a pile of native macOS utility surfaces that make the product feel inhabited on first launch instead of empty.

It also ships communication where most terminals would not even try. Chat, mail, and calendar are all separate Go TUIs. Mail and calendar use OAuth with PKCE and store tokens in the macOS keychain. Chat runs through mediated YEN-owned API surfaces, binds identity server-side, and keeps anonymous direct database access intentionally closed. None of that exists as novelty for novelty’s sake. It exists because I think the terminal can hold more of a working environment than most tools assume, especially when it removes the lazy default of making you tab back out to a web app for a workflow you were already in the middle of.

The Terminal-First IDE Part.

The newest layer is the one I cared about most going into this milestone. I did not want YEN to say “terminal-first” and then quietly shove the serious workflows into a browser pane, a cloud dashboard, or a second application model. I wanted the terminal to stay central.

That is why the IDE layer stays honest about what it is doing. If YEN is using live LSP, it says so. If it falls back to AST, it says so. If a project has not been trusted, it says so. If a share session exists, it is explicit. If a command is risky, the gate should behave like it. The command palette is not just a launcher any more. It is a terminal-native IDE entry point. The native macOS review and merge-conflict windows are not an escape hatch away from the terminal. They are closer-to-the-metal extensions of the same workflow.

That distinction matters to me. I am not trying to cosplay as a giant editor suite. I am trying to build an IDE around the place where engineers already end up doing the real work.

The Technical Patterns That Made It Work.

The most important pattern in YEN is vendor, do not fork. The upstream terminal engine stays mirrored as an exact upstream tree. YEN-specific behavior lives in overlays and integration layers. The same philosophy shows up in bundled tools. If an upstream project already does the job well, I would rather integrate it carefully than reinvent it badly just to preserve some fantasy of purity.

The second pattern is native-first. If macOS already has the right API, I want to use the OS instead of shipping a giant dependency. That is why YEN uses native helpers for video, PDF, and SVG preview paths, native keychain handling, native notification delivery, native screenshot flows, and native AppKit utility windows.

It is also why the bundle shed a ridiculous amount of weight: Replacing ffmpeg, poppler, and 7zip-style baggage with native helpers and system tooling saved about 258.8 MB compared with the heavier alternative. That kind of decision is not glamorous, but it changes what the product feels like to install, ship, and maintain.

The third pattern is trust before convenience. I do not want silent authority. Project trust, environment trust, LSP trust, sharing trust, workflow trust, and release verification all exist because I would rather add a little ceremony than hide risk behind a friendly button label.

The Native macOS Bet.

YEN is intentionally macOS-first. That is not an accident and it is not a temporary inconvenience I keep apologizing for. It is the product bet.

The clearest example is speech-to-text. Press Option + Space and YEN can capture audio, transcribe it on-device using Apple’s speech stack, show live state in a floating overlay, recover cleanly when permissions or local speech assets are missing, and insert the result back into the active context.

That works inside YEN and across other macOS apps. The same native bet shows up in settings, preview helpers, notifications, launch-at-login behavior, keychain-backed auth, screenshot tooling, and the command-palette-driven utility surfaces.

The trade-off is obvious. I do not get to claim “runs everywhere.” The upside is just as obvious. I get depth instead of pretending that a lowest-common-denominator abstraction is enough.

What the Repo Says.

I did not want this post to hand-wave the effort. The numbers below are the repo snapshot as of March 29, 2026:

• Start: November 6, 2025

• Commits: 4,616

• Time: 144 days

• Average: 32.06 commits per day

• Lines of Code: 136,000

• Contributors: 1

And yes, the contributor count is the part that still hits me emotionally. There is no hidden engineering org behind this post. It is just me, the repo, the build system — which is cool af — and the users, and a stupid number of tiny decisions stacked on top of each other until they started to look like a product.

But I made it.

The Scope Was Bigger Than One App.

YEN stopped being "one app" a while ago. The repo includes the marketing site, the release metadata surface, the desktop app, the overlay system, build and release automation, the CLI entrypoint, chat, mail, calendar, shared auth packages, database migrations, docs, tests, and a fairly serious asset pipeline.

Yeah, it’s a lot.

That breadth is exactly why I keep describing YEN as a system. The desktop app matters, obviously, but the product is also the release harness, the signing discipline, the docs, the migration logic, the auth model, the sound-pack delivery, the updater, the whitepaper, and the public website that stays in sync with what ships.

I’m pretty fucking proud of it all, to be honest.

What I Learned Building This Alone.

A few thoughts on this topic, while we’re here:

1. Scope is survivable if the system is honest. A repo this broad only stays manageable if the build fails loudly, the trust model stays explicit, the docs remain current enough to lean on, and the release path is deterministic enough that I can sleep after a ship.

2. Shipping teaches faster than theorizing. I could have spent another six months polishing a grand story about terminal-first computing. That would have been a mistake. The actual product got better because I shipped, watched where friction showed up, fixed it, and repeated that process an embarrassing number of times.

3. Documentation is leverage. The 15k lines of docs in this repo are not decoration. They are a force multiplier. Once a project gets this broad, undocumented decisions become a tax on every future change, especially when the future developer is still just me.

4. Taste matters. I do not buy the idea that taste is fluff. Taste is what decides whether a shortcut belongs, whether a command palette feels honest, whether a panel deserves to exist, whether a feature should stay terminal-native, whether a native window is warranted, and whether a clever abstraction is actually making the product worse.

5. Solo does not mean small. Solo still means constrained. It still means trade-offs. It still means there are things I cannot do yet. But it does not have to mean shallow. With the right architecture, automation, documentation habits, and release discipline, a solo developer can build something wide and deep without pretending it is small.

This has been a very fun trip and one that’s just beginning since it’s a daily tool that I need to use to feed and clothe myself. So, I’ll be here for a while, cranking on YEN every single day because I just really, really, really like it.

YEN isn’t just a fast terminal. It is not just a speech-to-text experiment. It is not just a file browser wrapper. It is not just a fun macOS utility surface. It is a terminal-first IDE platform with a clear thesis, a local-first core, explicit trust boundaries, a real shipped IDE layer, native macOS depth, bundled first-launch usefulness, and a release system that can keep up with the ambition of the product.

And that’s what the milestone marks.

Not perfection.

Not completion.

Clarity.

What Comes Next.

There is still a lot left to do. There is more IDE depth to build, more workflow hardening to do, more collaboration and review ergonomics to refine, more polish to add to the native surfaces, and more places where trust, diagnostics, and context can get sharper.

But I feel very differently about the project now than I did a few months ago. The shape is clear. The identity is clear. The system can carry the ambition now.

If you have been following along, testing builds, reading posts, reporting bugs, or just quietly paying attention while I kept shipping into the void, thank you. This milestone has my name on it in git history, but no product gets here in a vacuum. The feedback loops mattered. The curiosity mattered. The pressure to keep the quality bar high mattered. It helps. I’m grateful.

YEN v1.0 is here, and I’m just getting started.

— 8

There’s a small feature in the latest YEN release that I’m weirdly proud of, and it took me longer to design than to build: The background image and wallpaper scope toggle.

Subscribe now

This is the second part of the, well, first part about wallpapers.

The Question Nobody Asks but Everyone Has

When you set a background image in YEN, what does “background” mean?

If you have three splits open — one running tests, one tailing logs, one with your editor — does the image live behind all of them? Just the focused split? The whole window? If you open a new tab, does that tab get the image too?

This is one of those settings that feels obvious until you try to define it.

I went through a few different mental models before landing on the one we ship:

1. Global (all windows) — The image is a wallpaper. It’s yours, not the terminal’s. Wherever YEN renders, the image is there. Good for people who set one image and forget it.

2. Per-tab — The image belongs to the current tab’s context. Switch tabs, different look. Split panes within a tab share the same image. This is the default because it maps cleanly to how most people think about “what I’m working on right now.”

3. Per-split — Maximum granularity. Each pane is its own visual context. You can have a dark ocean render behind your SSH session and a warm linen texture behind your local dev split. This is for people who want their terminal to reflect what each pane is doing.

But, ultimately I wanted to keep it simple. Here’s the experience:

Start with a blank canvas, your Terminal. And then you can add an image:

Or you can make the images per split:

Pretty neat and as I’ve said before, it makes it feel so much more personal. And that’s the update folks. Enjoy.

— 8

I built a background image upload that just makes it feel more like your own personal space. It’s available directly via the Settings Panel and there you go, magic.

Subscribe now

It’s stored locally in Application Support and is repeated through splits:

The Buster Sword is the GOAT:

Have fun with it! There’s also a setting I’m building which will make it either work in each and every splits — repeating, of course — or to just be a single background across all splits. I’ll have that posted in the next release soon.

— 8

The first IDE post was about ambition. The second one was about cohesion. This one is about proof (or the burden of proof). Because if you can’t trust your Terminal and IDE to do what you want, then, what’s the point?

It has to work. Or it doesn’t.

Subscribe now

You see, a Terminal-first IDE cannot stop at having a lot of commands, and it cannot stop at having those commands point at each other in mostly sensible ways. At some point the product has to answer the question that matters more than all of that: When it tells me something about my repo, should I believe it?

That is the standard that anyone should hold any Terminal to and it’s the standard that I hold to the work that I do for this tool and our growing community of users.

I do not want an IDE that performs confidence; I want one that can defend its claims. I want it to be explicit about what it knows, what it does not know, which local facts produced the answer, where the boundary of authority ends, and what has to stay a human judgment call.

If the terminal is going to remain the center of gravity, it needs to feel less like a loose toolkit and more like a system with a memory, a vocabulary, and a conscience.

That is what this phase of YEN has been about and what is necessary before I feel comfortable giving this project a real v1.000 stamp.

Readiness Has to Reuse the Evidence Model

The clearest example is yen ide merge-readiness.

Before a branch is ready, I usually already have the evidence somewhere. The repo has a working tree state.

yen ide doctor knows whether the workspace is healthy.

yen ide trust status knows whether the repo has been explicitly trusted.

yen ide verify status knows whether readiness and security gates have actually run.

Git knows how large the diff is and which files look risky. The local timeline already knows what the recent gates and review surfaces have done. Sometimes GitHub metadata is available too.

The problem was never missing evidence. The problem was fragmentation.

Once a repo gets large enough, the cost of answering a simple question like “is this safe to review?” is no longer the cost of one command. It is the cost of rebuilding the same mental model from half a dozen surfaces every single time. That is exactly the kind of work I think an IDE should eliminate.

What I did not want was the obvious fake solution.

I did not want a separate readiness database. I did not want a second approval workflow. I did not want a new trust vocabulary that would immediately start drifting from doctor, verify, review, and timeline. That is how tools become bureaucratic. They solve a visibility problem by creating a state problem.

So merge-readiness is not another authority surface. It is an aggregation surface over the evidence model that already exists.

It reads the current doctor state, trust summary, verify readiness and security snapshots, git diff heuristics, risky-file context, local gate and review history, and optional current-branch PR metadata when that exists. Then it gives me one recommendation: safe to review, safe to merge, or needs human check.

The label matters less than the defense behind it. If checks are missing, it says so. If security is blocked, it says so. If review state is still draft or changes-requested, it says so. If the repo has no baseline evidence at all, it does not pretend a green answer exists. It stays conservative and tells me exactly which facts are making it uncomfortable.

That is the point. I do not think users want a prettier green badge. I think they want a tool that can justify the badge.

The Cost Model Has to Stay Honest Too

Trust is not only about correctness. It is also about cost.

An IDE can have a convincing readiness story and still betray the user if every new layer quietly makes the terminal slower, heavier, and harder to reason about. I did not want to argue that the terminal can be the IDE while hand-waving away the performance bill.

That is why I shipped yen ide benchmark status and yen ide benchmark run.

I wanted proof checked into the product instead of folklore. The benchmark harness runs deterministic suites for search latency, LSP startup latency, verify duration, and orchestration control-plane overhead. It records cold and warm timings, captures an environment stamp, writes a latest report, compares against a saved baseline, and fails closed when the proof is missing or when a regression is large enough that I should treat it as real.

That fail-closed behavior matters. I did not want a benchmark surface that always sounds informative but never has consequences. If YEN is going to claim trust, its performance evidence has to be usable as a gate, not just as dashboard decoration.

I also wanted the performance story to reuse the same discipline as the readiness story. So the benchmark harness does not invent a separate telemetry universe. Its suite latencies are mirrored into the same non-interference SLO ledger that already exists. Search, LSP startup, verify, and orchestration become explicit entries in one guardrail story instead of becoming a second performance control plane.

The fixtures matter just as much as the ledger. I did not want these numbers to depend on whichever repo happened to be under my cursor or whichever binaries happened to be installed that morning.

So the default path uses shipped fixtures under yen-cli/fixtures/ide-benchmark. Search and LSP run against a known TypeScript-shaped fixture. Verify runs against a deterministic local package-script fixture. Orchestration runs against mock adapters on a fixture-provided PATH. That gives me repeatable proof instead of a moving target.

The terminal-first bet gets stronger when the cost model is explicit. It gets weaker when the cost disappears into vibes.

A Semantic Target Has to Survive the Handoff

There is another way to lose trust that is easier to miss.

The product can have an honest evidence model and an honest cost model, and still feel unreliable if the moment I try to act on that evidence the target gets lost between surfaces. A diagnostic that cannot land in the right file is not much better than a guess. A review hunk that jumps to the wrong place erodes confidence far faster than a missing feature ever will.

That is why I shipped yen ide open, moved yen-yazi-edit onto the same launcher contract, and then pushed that same contract into the native macOS review surfaces.

The rule is simple: Every semantic target stays path:line[:col] all the way through.

Search results, diagnostics, verify output, PR review hunks, merge-conflict selections, and file-browser edit targets should not each invent their own editor-jump syntax. They should all reduce to one location contract, then let one planner decide how that target becomes a real editor launch.

That planner now resolves repo-relative paths, preserves quoted VISUAL and EDITOR argv, understands the editor-family goto matrix, and exposes an explicit dry-run plan so I can test the launch behavior before it surprises a user.

Code-family editors use --goto. Zed takes the direct target shape. Xcode goes through xed --line. Terminal editors keep their real line-aware capabilities where they exist. Plain editors fall back to opening the resolved file only, with the loss of line-awareness made explicit instead of being silently swallowed.

The important part is not the matrix. The important part is the failure behavior.

This handoff now fails closed when the target no longer exists. It fails closed when the launcher is unavailable. If nvr is configured but there is no running server, it falls back to nvim instead of pretending a dead attach command counts as parity. Yazi uses the same planner. And on macOS, the native PR review and merge-conflict workspaces now go through the bundled yen ide open bridge for recognized GUI editors instead of maintaining a second Swift-only launch matrix with its own drift risks.

The same rule now applies to live LSP mutation. yen ide lsp code-actions takes that same semantic target, forwards matching diagnostics context when the server can actually use it, previews every returned action, and only auto-applies when there is one pure workspace edit to defend.

If the server returns multiple edit choices, a command-only action, an edit-plus-command action, or a disabled action, YEN stays in preview mode and says why. That is less magical than a universal quick-fix button. It is also much easier to trust.

That sounds like glue code. I think it is part of the trust model.

The reason is simple: if the product tells me where to look, it has to prove it can actually take me there.

Debugging Has to Leave Evidence

A debugger is where integrated tools often fall back into folklore.

A failing test might know the file. A review surface might know the risky hunk. A diagnostic might know the exact line. But the moment I want to cross from evidence into execution, a lot of products suddenly expect me to carry all of that context by hand, rebuild a launch command from memory, and trust that whatever happened in the debugger can somehow be rediscovered later.

I did not want that split either.

So the debugger work stayed on the same semantic target contract and the same trust model as everything else. yen ide debug status and yen ide debug start use the same path:line[:col] vocabulary as search, diagnostics, review, and handoff.

The shipped baseline is intentionally narrow: python-pdb, node-inspect, and lldb for the local, SSH-backed, and tracked-devcontainer cases I can actually defend. The product stays explicit about what is still blocked: attach-to-pid flows, TypeScript direct-file launch, package-debug flows, and any zero-config adapter install story beyond that shipped baseline.

The more important part is what happens after launch. Real debug runs now write summary, log, and transcript evidence into the same per-workspace state model. yen ide debug status can show me the last run. yen ide trust status can point back to the same artifacts. Timeline events carry the report paths forward. Managed local, SSH-backed, and tracked-devcontainer sessions all stay on that one surface. The debugger is not a private side quest anymore. It leaves a paper trail the rest of the IDE can reuse.

That is also why the visual layer came last. yen ide debug tui now renders the same managed-session state, source excerpt, breakpoints, watches, recent output, and transcript tail instead of inventing a second debugger UI with its own hidden state. When the file is local, the source panel is real. When the workspace is remote, the dashboard says so instead of pretending it can render code it does not actually have. The UI inherits the trust model instead of overriding it.

The same restraint now shows up in the macOS command palette. Empty-query quick IDE actions for Debug Status, Debug TUI, and Format / Lint / Fix Status are just thin launchers over the shipped CLI surfaces. They make the trustworthy path faster to reach without creating a parallel native-only debugger or quality model that would immediately start drifting from the terminal.

That makes the surrounding surfaces sharper too. yen ide test status, yen ide verify status, yen ide search, yen ide merge-readiness, yen ide pr-review, and local diagnostics only append a yen ide debug start ... handoff when the shipped debugger can genuinely launch that target. If it cannot, YEN stays quiet instead of pretending a button is better than an answer.

This is the same trust rule again: Do not promise execution where only suggestion exists. A terminal-first IDE should be willing to leave capability on the table if that is what it takes to keep the chain of evidence intact.

Remote Work Needs One Identity and One Vocabulary

Remote collaboration is where trust models usually split apart.

It is very easy to add SSH-backed behavior to a product by quietly inventing a second control plane. Local work starts using one vocabulary. Remote work starts using another. The same repo gets described differently depending on which side of the network boundary I am standing on. Status gets fuzzy. Trust becomes suggestive instead of explicit.

I did not want that.

So the remote work extended the existing yen ide surfaces instead of branching into a separate remote subsystem. yen ide detect accepts ssh://user@host/abs/path targets. So do yen ide doctor, yen ide trust status, and yen ide verify status.

The point is not that everything suddenly runs remotely. The point is that the same workspace identity now anchors both the local and SSH-backed view of the same repo.

That shared identity matters because it keeps the evidence story coherent. Remote detection reports where execution is actually happening. Trust and verify summaries key their local evidence against that shared workspace identity instead of pretending a remote repo is just another local path. Remote share state does the same thing. yen ide share host, share status, share revoke, share trust, and share untrust now speak the same target shape and the same identity model.

The lifecycle language got stricter too, because vague state is what makes remote tooling feel untrustworthy.

If the host is temporarily unreachable, a session should not suddenly look stale. Disconnected and stale do not mean the same thing. Disconnected means the runtime may still exist and the control plane has temporarily lost contact. Stale means the runtime is gone. YEN now preserves that distinction, keeps reconnect metadata explicit, and lets share status fall back to cached local metadata when the network is the only thing missing.

That is not a flourish. That is the difference between a system that tells the truth under stress and one that collapses into hand-waving the first time SSH gets weird.

Remote Execution Still Has to Admit Its Limits

The last piece of trust is restraint.

Once a remote identity model exists, it becomes very tempting to make every remote surface sound complete the moment SSH works once. That would have made for a cleaner demo. It also would have been dishonest.

So I kept the execution story explicit instead.

Remote workflow discovery is there, and so is real remote execution. yen ide workflow discover, list, show, and run all accept the same remote target shape now. Authored workflows and repo-native tasks can execute remotely over SSH on the same workspace identity, with trust, approval, reports, and timeline ownership staying local.

What is still blocked is the part I cannot defend quite yet: Remote --watch loops and any fake suggestion that the remote machine is under a richer control plane than it really is.

The same rule applies to devcontainers. yen ide devcontainer status, up, shell, and down now work for SSH-backed targets too, and the debugger can reuse that same tracked runtime through yen ide debug status --devcontainer and yen ide debug start --devcontainer when the separate devcontainer trust and health checks are satisfied. If the remote machine is missing the right CLI, the product says so.

If the tracked local state and the probed remote state disagree, the product says so. Labels like spec-drift, disconnected, and missing-remote-cli exist because a terminal-first IDE should not imply a healthy runtime it never actually verified.

That is the restraint I care about now. Ship the remote execution paths that are real. Keep trust and evidence local and explicit. Keep blocked features blocked until the control plane is strong enough that a nicer interface would not just be hiding drift.

This is the part of terminal-first IDE design I care about most now.

The product gets better when it becomes more articulate about boundaries, not less. It gets stronger when the same evidence model is reused in more places, when the same semantic target survives more handoffs, when the same workspace identity survives distance, and when the system is willing to say “I can inspect this, but I cannot honestly claim to control it yet.”

That is what earning trust looks like.

The thesis was that the terminal can be the IDE. The second post was about making that IDE hold together. This phase was about something stricter: Making it legible enough, measurable enough, and self-aware enough that I can trust it when the work gets real. That’s always been the standard.

And now it’s the standard for YEN moving forward. As it should be.

More work to come.

— 8

Last week I published an important post about how the Terminal is the IDE now and I’ve been working on making it even better.

You see, that first post was the thesis. The terminal should not be a utility room bolted onto the bottom of an editor. It should be the place where engineering work actually stays coherent. It just makes sense.

Subscribe now

This follow-up is about something slightly less glamorous and much more important: Making that IDE layer behave like one system instead of a pile of unrelated features.

Because that is the real test.

Anybody can ship a burst of commands and a few native windows and call it an IDE story. The harder part is preserving context across those surfaces, making trust legible, staying honest about what is actually answering a query, and meeting repos where they already are instead of inventing a second configuration universe.

So that is what the most recent hardening pass was really about. Here’s what’s up and the details of what I’ve added.

1. Make the Output Survive the Workflow

The biggest change was not one flashy feature. It was a contract.

I wanted YEN to stop flattening useful engineering output back into vague text the moment it crossed a surface boundary. If a result points at a real file and line, that location should survive through the terminal, the command palette, the review flow, and the native macOS windows.

So the system now leans much harder on one shared semantic location model: path:line[:col].

That shows up in yen ide parse --format tsv, in verify reports, in workflow reports, in the command palette search path, in yen ide pr-review, and in the merge-conflict workspace. Content hits, diagnostics, review evidence, workflow output, and conflict selections can all point back to the same kind of target instead of degrading into “open this file and good luck.”

That sounds small until you use it.

Once the location contract stays intact, the command palette stops feeling like a launcher with some extra sugar on top. It starts feeling like a terminal-first IDE control plane. A search result can still be a real action. A review hunk can still be a real place. A test failure can still be a real jump target.

That is the difference between “there is a lot here” and “this actually holds together.”

2. Upgrading Git Review without Becoming Git

I also spent a lot of time strengthening the review baseline.

That did not mean building a separate Git universe inside YEN. I still think that would be the wrong move. The CLI should stay the source of truth. But the review path needed to get more capable and less lossy.

So the current baseline is now bundled lazygit plus bundled delta as the shared diff renderer. On top of that, yen ide pr-review picked up deterministic hunk inventory and semantic hunk targets, while the macOS PR review workspace and merge-conflict workspace both learned how to stay anchored to those same repo targets.

That has a few nice and positive effects.

Focused hunk previews are better. Plain-text fallback is explicit instead of pretending it is the same thing. Selected files and hunks can keep their target identity all the way through a review flow. The PR evidence path can carry the latest verify readiness and security snapshot with it. And the merge-conflict workspace can show a delta-backed patch preview, keep the selected hunk as a real location, and hand that target off to the editor before staging.

That is exactly the division of labor I want. Keep the terminal-native review flow in the terminal. Use a richer native surface when it genuinely helps and don’t try to pretend that the native surface is replacing the terminal.

Makes sense, right?

3. Trust, Doctor, and Verify Finally Read Like One Story

Another major improvement is that repo state is much easier to inspect before something goes wrong.

YEN already had a lot of the raw ingredients: Project trust, env trust, LSP trust, share trust, workflow trust, local verify artifacts, devcontainer state, language-server status, and so on. The problem was not missing data. The problem was legibility.

That is why yen ide doctor matters.

It takes the existing sources of truth and turns them into one repo-health snapshot with project context, toolchain and version signals, trust and runtime summaries, verify readiness, security state, and clear blocker versus warning findings. By default it exits non-zero when blockers exist, and --strict can intentionally make warnings fail automation too. It is deliberately direct. A health command that only tells you that it successfully collected state is not useful.

The same principle drove the workspace trust center. yen ide trust status gives one aggregate view over the trust and runtime or session state YEN already had. yen ide trust revoke and yen ide trust reset delegate back to the owning commands instead of mutating trust state behind their backs. That keeps the control plane honest.

And then there is the verify path.

yen ide verify status is now a read-only snapshot over the latest local verify artifacts, while yen ide verify carries explicit local osv-scanner coverage. More importantly, that readiness and security state is no longer trapped inside one command. It can surface in doctor and in PR evidence previews too.

That matters because security is not a separate product. It is part of whether a repo looks ready to act on right now.

4. Meet Repos Where They Already Are

This is one of the places I care most about not getting cute.

A lot of developer tools become less trustworthy the moment they stop respecting the repo in front of them. They invent a second workflow system, a second task runner, or a second configuration universe and then ask you to keep both in your head forever.

I do not want that.

So a lot of the recent work was about making YEN better at reading the repo’s existing signals and putting them on one control plane.

yen ide workflow discover now inventories package scripts, Make targets, Just recipes, and Taskfile tasks with provenance, category, risk, and conflict visibility. yen ide workflow run --native is the explicit path for running one of those discovered tasks without pretending it is an authored YEN workflow, and it reuses the same trust, approval, timeline, and reporting plumbing as the rest of the workflow surface.

The quality surface follows the same rule. yen ide format, yen ide lint, and yen ide fix prefer repo-native tasks first, fall back narrowly when the repo already implies a toolchain, reuse the existing trust and approval model, and write dedicated quality reports instead of disappearing their behavior into a black box.

The test surface does too. yen ide test status and yen ide test run build on the same repo-native runner detection and verify artifacts instead of inventing a second language matrix just for testing. Grouped failures, rerun-failed behavior, and semantic jump targets all sit on that same baseline.

And the VS Code migration path got more serious in the same spirit. yen ide vscode inventory and yen ide vscode import now produce richer extension guidance, task and test parity notes, and deterministic local artifacts like migration-report.json and manual-cleanup.txt under .yen/vscode-import.

The common theme is simple: I want YEN to reduce ambiguity, not replace the repo with a parallel religion.

5. Honest Polyglot Intelligence > Pretend Coverage

The code-intelligence layer also got sharper, and I am happy about this one because it pushed the product further in a direction I care about a lot: Honesty.

In the first post about a Terminal-first IDE I said I do not want “smart” terminal tooling that lies. That rule matters even more once multiple languages and multiple fallback modes are involved.

So the install and fallback story is much more explicit now.

JavaScript and TypeScript share one managed baseline. Python and Go have their own managed paths. Rust points at rustup. Swift points at the Xcode or Swift toolchain. Zig expects zls on PATH. YEN does not silently blur those operational models together.

The AST side got stronger too. yen ide ast status, definition, and references now have real parser-backed fallback for Python, JavaScript and TypeScript, Go, and Swift, and the output says what is actually answering the query: python-ast, typescript-compiler-api, go-parser, or swiftc-dump-ast-json. Those results stay clearly labeled Source: ast so fallback never masquerades as live LSP.

Unsupported languages stay explicit instead of getting vague marketing support. Bun-backed JavaScript projects also stop falling off the AST path just because the runtime detection looked slightly different from the normalized JS family.

That is the kind of improvement I want from this layer.

Not bigger claims. Clearer contracts.

6. The Boring Internal Work Is Product Work Too

There was one other slice in this pass that matters even though it is much less visible from the outside: the IDE CLI modularization work.

I do not want every future IDE feature to keep piling into one giant Bash entrypoint until the safest answer becomes “please do not touch this file.” That is how products slow down. That is how regressions get stickier. That is how shipping momentum dies.

So the router and bootstrap layer stays stable in yen-cli/commands/core/ide, while the shared helpers and capability families live in sourced modules behind explicit loader-contract checks.

The user-facing CLI did not change. The implementation risk did.

If you want to feel the current shape of the terminal-first IDE layer, this is a pretty good compact path:

bash
yen ide doctor
yen ide trust status
yen ide lsp status
yen ide ast status
yen ide workflow discover
yen ide workflow run --native package:test --dry-run
yen ide format status
yen ide test status
yen ide verify status
yen ide pr-review 123 --list-hunks

And if you are on macOS, press Cmd + Shift + P after that.

Search the repo. Open a review surface. Inspect diagnostics. Jump to a hunk. Pull up trust state. Notice how often the system can keep the location, the context, and the repo identity intact instead of making you reconstruct it by hand.

That is what this follow-up post is really about. The first post in the series was about saying the terminal is the IDE now.

This one is about making that sentence even more true.

There is still more to do. Editor handoff parity, remote parity, merge-readiness reporting, and benchmark work are all still on the table.

But the IDE layer is already better now in the ways that matter most to me: More coherent, more inspectable, more honest, and more native to the repo that is actually in front of you.

I like where we’re going together.

— 8

There is a pattern I have been watching for years.

Most developer tools say they love the terminal, then quietly treat it like a basement utility room. And it always kind of feels like it lives in the basement at the bottom of the screen, right?

Subscribe now

The editor gets the architecture. The terminal gets a small panel.

Boohiss.

The editor gets the first-class search, the code intelligence, the review flows, the collaboration story, the automation surface, and the gentle product language about focus and speed. The terminal gets a rectangle at the bottom and maybe a button that says “open integrated terminal.”

I never thought that that was good enough, at least from my perspective!

The terminal is not a sidecar for serious engineering work. It is the place where code actually meets reality. It is where builds fail, migrations go sideways, diagnostics become actionable, PRs get reviewed, services get restarted, environment mistakes surface, and dangerous commands should feel dangerous before you press Enter.

That is why I have been pushing YEN toward a different thesis: Do not bolt a terminal onto an IDE. Build the IDE around the terminal.

And the most recent release — v0.999 — is the biggest step so far in that direction as YEN now ships a real terminal-first IDE surface.

Not a concept page.

Not a chat sidebar pretending to be an IDE.

Not a cloud account plus a terminal skin. Eww.

Nope. None of those things. Instead, we have a real, local-first workflow stack that starts in the terminal and stays there unless a richer native macOS surface is actually justified. Here are the 8 major pieces that bring it all together.

1. Project Awareness

The first big piece is project awareness.

YEN now understands enough about the current repository to make terminal workflows feel contextual instead of generic. yen ide detect finds the project root and runtime / tooling context. yen ide env gives you explicit trust-gated environment loading. yen ide history, replay, and profile turn the terminal into something closer to a project memory instead of a disposable scrollback trench.

That matters because terminal-first tooling only works if the terminal knows where it is, all the time, even when you forget.

2. Search with First-Class Objects

The second big piece is search that treats engineering artifacts like first-class objects.

yen ide search can rank across files, content, diagnostics, project history, and actions. On macOS, the same contract now powers the desktop command palette. Empty query launches actions.

A typed query searches built-in actions first, then falls back to project files, content, diagnostics, and recent history for trusted local repos. That means the search surface you invoke with Cmd + Shift + P is no longer just a launcher.

It is a project-aware terminal IDE entry point.

3. Local Code Intelligence

The third big piece is local code intelligence.

YEN now ships an explicit LSP control plane with yen ide lsp trust, start, status, diagnostics, hover, definition, references, rename, stop, and a bounded install matrix. Cool.

This all includes real resolver-backed supervision when a local language server exists, placeholder guidance when it does not, grouped diagnostics snapshots with freshness labeling, and interactive request surfaces that stay honest about whether they are using live LSP or syntax-aware fallback.

That last part matters to me a lot. I do not want “smart” terminal tooling that lies.

If YEN is using a live language server, it says so. If it is using AST fallback, it says Source: ast. If the language is unsupported or the expected local server is missing, it says that too.

Honesty is a feature. Who would have thought.

4. Syntax-Aware AST Queries

The fallback layer is the fourth piece: Syntax-aware AST queries.

When live LSP is not available, YEN can still answer useful structural questions with yen ide ast status, definition, and references for the currently shipped languages.

That means the terminal does not have to collapse all the way down to dumb text search every time a full server is absent.

5. Execution Discipline

The fifth piece is execution discipline.

This is where terminal-first IDEs have a chance to be better than editor-first ones. Or that’s the hope!

YEN now ships yen ide explain for failed command analysis, yen ide verify for multi-language verification bundles, yen ide gate for risk-aware approval checkpoints on dangerous commands, yen ide workflow for schema-validated project workflows, yen ide timeline for local audit events, and yen agents for first-party adapter coordination. Wild.

There is also yen ide pr-notify for GitHub review-request polling and yen ide pr-review for focused diff review, evidence bundles, inline comments, and explicit review decisions.

This is not about adding ceremony.

It is about making the terminal better at the parts of engineering work where context, the ability to easily review work, and general safety actually matter.

6. Collaboration without Bloat

The sixth piece is collaboration without a custom relay empire.

YEN now ships yen ide share status, host, join, revoke, trust, and untrust using an integration-first transport model: upterm first, tmate as fallback. Share tokens are encrypted locally. Hosting is per-project and explicitly trusted. Join flows validate the token locally before any transport command runs. Sessions can be read-only or interactive. TTL expiry and immediate revoke are part of the contract.

This was an important design choice.

I did not want to build a bespoke terminal-sharing service just to say YEN has collaboration, which would be fun but not entirely useful.

You see, there are good maintained tools for this job already. The right move was to build the control plane, trust model, audit trail, and operator ergonomics around them instead of pretending every feature needs a net-new backend.

7. Environment Parity and Migration

The seventh piece is environment parity and migration.

YEN now ships yen ide devcontainer status, up, shell, and down as a trust-gated wrapper around the reference devcontainer CLI. It is intentionally local-workspace scoped. No hidden runtime. No bundled container stack.

No pretending YEN needs to become Docker Desktop.

YEN also ships yen ide vscode inventory and import so teams can inspect existing VS Code workspace config, classify what is supported or partial, and write deterministic YEN-local migration artifacts without mutating the original workspace by surprise. Dry runs emit real diffs. Applied writes are convergent. That is the kind of migration behavior I want from tooling: boring, inspectable, and reversible.

8. Native macOS IDE Surfaces That Actually Help

The eighth piece is native macOS IDE surfaces where they actually help.

This is the part that makes YEN feel different.

The command palette now exposes quick IDE actions like IDE: LSP Status, IDE: LSP Diagnostics, IDE: LSP Install Matrix, IDE: Share Status, IDE: Share Host (Read-Only), IDE: Share Revoke, IDE: Devcontainer Status, IDE: VS Code Inventory, IDE: VS Code Import (Dry Run), and IDE: AST Status.

On top of that, macOS now has a dedicated desktop PR review workspace and a dedicated desktop merge-conflict workspace launched from the same palette. Those are native surfaces, not browser panes, and they stay anchored to the active repository context instead of trying to replace the terminal.

That is the pattern I want YEN to keep following.

If a task is fundamentally terminal-native, keep it in the terminal.

If a task genuinely benefits from a richer surface, build a native one and keep it close to the terminal instead of escaping into a second application model.

That is a better division of labor than the one most IDEs settled on.

Bonus: Local First

There is also a security and trust story here that I think matters more than the marketing layer most developer tools put on top.

This IDE stack is local-first. Project trust is explicit. The LSP runtime is per project. Sharing trust is per project. Diagnostics snapshots are local.

Devcontainer orchestration shells out to the reference CLI you already chose to install. VS Code import writes project-local artifacts instead of disappearing into a hidden sync service.

None of that is as flashy as saying “agentic workspace intelligence” in a launch trailer, but I think it is the right way to build tools engineers can actually trust.

And there is still plenty left to do!

Debugger work remains future work. Remote devcontainer parity is still a deliberate follow-up instead of a hand-wavy promise. Agent-runtime hardening and context reliability still have room to grow. I am not pretending YEN is finished.

But the shape is real now. You can feel the product thesis in your hands.

The command palette is not just a launcher anymore. The terminal is not just an output window anymore. The IDE is not somewhere else anymore.

It is here.

If you want a feel for the surface area, this is a compact starting path:

bash
yen ide detect
yen ide env list
yen ide lsp status --format json
yen ide lsp diagnostics
yen ide lsp hover src/app.ts:12:3
yen ide share status
yen ide share host --read-only --ttl-minutes 30
yen ide devcontainer status
yen ide vscode inventory
yen ide search verify
yen ide verify --quick
yen ide pr-review 123 --loop
yen ide timeline --limit 20

And if you are on macOS, press Cmd + Shift + P and start from there.

That shortcut has quietly become one of the best ways to feel the whole philosophy of YEN in a few seconds.

Open the palette. Launch a real IDE action. Search a repo. Review a PR.

Inspect diagnostics. Start a share session. Import a VS Code workspace in dry-run mode. Then close the palette and notice that you never left the terminal-first workflow to do it.

That is the point.

The goal is not to cosplay as a giant editor suite. The goal is to make the terminal powerful enough, contextual enough, and trustworthy enough that you stop needing to flee from it for everyday engineering work.

That is the release. That is the mission.

And for the first time, I think it is fair to say it plainly:

The terminal is the IDE now. About damn time.

— 8

There is a version of speech-to-text that looks great in a demo and still feels wrong in daily use. You hold Option + Space. You speak. You release.

Wow. So much wow.

Subscribe now

And it worked. YEN has had a strong speech-to-text foundation for a while now. It is on-device. It is native. It works across macOS apps. On macOS 26 and newer it uses Apple’s modern speech stack with unlimited sessions.

That part was never the problem.

The problem was simpler and more important. The workflow itself needed to be tightened. So, that’s what I’ve been working on since we’re coming up on our official v1.000 release — everything needs to be perfect.

But, there were some over-complications that I’ve wanted to fix and those fixes should be in as the right version of speech-to-text in a terminal-first IDE should not feel clever. It should feel dependable.

It should feel boring in the best possible way.

And, the rest of this post may be boring for most (a bit engineering and tech-heavy, so forgive me) but at the very least it showcases how much I care about this feature that’s a model for what and how I think about a Terminal-first IDE (platform).

If you want to geek out, continue on fellow nerd.

Hotkeys and Session Contracts

The first part of this hardening was the hotkey session contract.

The old problem space here was subtle. Global hotkeys on macOS are not just about catching one keyDown and one keyUp. You have to care about modifier-release ordering, event-tap rebuilds, trust loss, key repeat noise, and stop or restart churn when the user presses again quickly.

That means a sloppy implementation can accidentally treat keyboard-state drift as a real release. It can stop capture because polling noticed a mismatch instead of because the user actually let go. That is exactly the kind of thing that makes a feature feel haunted.

I tightened that.

Hotkey-up synthesis is now restricted to explicit recovery paths instead of loose session-state drift. The exact hold contract is deterministic whether Option or Space releases first. Event-tap rebuilds while the keys are still physically down no longer get to silently terminate a valid capture. Re-press during stop is treated as a queued restart instead of an invitation for stale state to bleed across sessions.

That sounds like implementation trivia until you use the feature all day.

Then it becomes the whole feature.

Finalization Contract for Acceptable Input

The second part was the finalization contract.

Speech-to-text gets weird when people talk about “the transcript” as if there is always only one obvious version of it. In reality there are partials, finalized segments, stop callbacks, error paths, watchdogs, and all the little ways asynchronous systems try to complete more than once or complete in the wrong order.

That is not acceptable for input.

YEN now treats stop completion as a proper per-session contract with one, single authoritative result. There is an explicit stop token. Completion is exactly once across normal release, recognizer error, results-stream failure, watchdog fallback, and forced reset paths. I also added more explicit stop telemetry so transcript loss can be diagnosed from logs instead of guessed from UI behavior.

Just as importantly, I removed “experimental” work from the default release-to-paste critical path. That part needed to happen.

If the user’s baseline expectation is “hold Option + Space, speak, release, paste,” then the core path cannot be hostage to optional experiments.

At that stage, Live Transcript Preview and Translate-on-Dictate were clearly labeled EXPERIMENTAL in Settings, and the default stop path was no longer forced to wait behind translation behavior when translation was off.

That product boundary was the right intermediate step: stabilize the core workflow first, then graduate optional surfaces only after the contract is clear.

Oh, fun.

The Contract for The Clipboard

The third part was the clipboard and paste contract. This was the most important user-facing fix.

The easy version of cross-app dictation is: Put text on the clipboard, fire Cmd + V, restore the old clipboard on a timer, hope for the best.

That is not a serious delivery contract.

If the paste target changes, if the synthetic paste does nothing, if the target app is slow, or if delivery simply cannot be proven, a timer-based clipboard restore turns into a data-loss risk. You get the worst combination: No inserted text and no recoverable text. No bueno, so, I tightened that too.

YEN now captures the insertion target at stop time and treats three cases separately: direct terminal-surface paste inside YEN, same-app responder-chain paste, and cross-app synthetic Cmd + V. Those are not the same operation and they should not pretend to be.

Inside YEN, the old clipboard can be restored after paste with a guarded delay. Same-app responder behavior stays explicit. Cross-app synthetic paste is treated more conservatively because delivery cannot actually be proven by the sender.

That means when YEN pastes into another app through synthetic Cmd + V, the dictated text now stays recoverable on the clipboard until the user replaces it.

That is a much better failure mode.

The goal is not to hide every edge case. The goal is to make the safe path the default path and the recovery path obvious when automation cannot honestly guarantee delivery.

I also tightened stale-target handling so the transcript is bound to the app or split that was focused when you released the hotkey. If that target changes or becomes invalid before insertion, YEN fails closed into manual recovery instead of pasting into the wrong place.

That is another example of the kind of boring behavior I want.

Wrong-field paste is worse than no paste.

Naturally.

Truth-Seeking in Great, Simple Product

The fourth part of this pass was simply telling the truth in the product and docs.

There was some confusion around Apple’s newer speech APIs, so I rechecked the recognizer shape carefully against Apple’s own documentation. Apparently, on macOS 26+, YEN still used SpeechAnalyzer with DictationTranscriber for the main dictation path.

That is the right pairing for what YEN is doing.

Apple also exposes SpeechTranscriber as part of the broader Speech framework stack, and it is useful, but it is not some magic replacement for session-logic bugs. SpeechAnalyzer is the container.

The real question is which speech module belongs in the workflow you are building. For YEN’s hold-to-talk dictation flow, DictationTranscriber remains the correct transcription surface.

That distinction matters because it keeps the engineering work honest.

If the problem is race conditions, stop semantics, target routing, and clipboard durability, the answer is not to wave at a nearby API name and hope the complexity disappears. The answer is to harden the workflow contract itself, so, that’s what the latest release has done.

And that ties directly back to YEN’s larger mission.

I keep saying YEN is a Terminal-first IDE, and I mean it in a very literal way.

The terminal should not just be fast. It should be trustworthy.

If a feature belongs in the terminal workflow, it has to clear a higher bar than novelty. It has to feel like something you can build real muscle memory around. It has to be explicit about what is experimental, explicit about what is guaranteed, and conservative when the system cannot actually prove success.

That is especially true for speech-to-text. Speech-to-text inside a terminal is easy to market as a fun trick. But in practice it is an input primitive.

It becomes part of how you move through the machine. Part of how you write. Part of how you reply in chat, search, command, annotate, and capture thoughts without breaking flow.

When something occupies that layer, reliability is the feature and everything else is secondary. So, this hardening pass did not add a dramatic launch trailer bullet point.

It did something better: It made the core path legible.

Hold Option + Space. Speak. Release. Done.

YEN should either paste the right final text into the right place exactly once, or leave that text recoverable so nothing is lost.

That is the bar. That is the contract.

And that is the kind of boring I want more of in software. Boring software is great software because it does precisely what I, and the community, want.

Who would have thought.

— 8

Quick story. I set up a brand new M4 Mac last week as a fresh-start check for YEN. Fresh macOS install, nothing carried over. Downloaded YEN, launched it, pressed Option + Space to dictate something.

Nothing happened. Damn.

Subscribe now

No error. No popup. No indication of what to do next.

That moment was a good reminder that onboarding is part of the feature. If speech-to-text is going to be something people rely on, setup has to be clear, guided, and accessible.

The dictation feature itself was not broken. What YEN needed was a better way to walk people through the permissions required to register the hotkey and capture audio. On an earlier build, that could leave Option + Space looking dead until someone manually dug through System Settings.

But, you know, onboarding matters. We all know it does.

YEN’s speech-to-text needs three macOS permissions to function:

1. Accessibility — The Option + Space global hotkey

2. Microphone — Audio capture for speech recognition

3. Speech Recognition — Apple’s on-device transcription engine

When any one of these is missing, speech-to-text can feel unavailable even when the fix is straightforward. That is exactly the kind of first-run experience we want to avoid.

macOS handles these permissions differently, especially Accessibility, so the app cannot assume the system will teach the user what to do. YEN now takes that responsibility more directly: show what is needed, explain why it matters, and make the recovery path obvious.

For a feature like speech-to-text, the onboarding experience is not separate from the feature. It is the feature. Naturally.

To make the experience even better I’ve made sure to expose the permissions in the Settings Panel and in the top macOS menu bar so the user has confidence that a fundamental part of their (new) workflow is always working.

Not hard to put together but important enough to build and ship. So give it a try!

— 8

We shipped a focused addition to speech-to-text in YEN: Translate-on-Dictate.

Subscribe now

The behavior is simple:

1. Hold Option + Space and dictate normally.

2. Release to finalize transcription.

3. If translation is enabled and the selected language pair is ready, YEN pastes translated text.

4. If not, YEN pastes the original transcript.

No extra prompt flow. No cloud dependency requirement from us.

Why This Is Experimental

Translation is now explicitly positioned as experimental and off by default.

That keeps the default dictation path stable while we gather real usage and edge-case feedback from opt-in users.

Core speech-to-text behavior stays unchanged when translation is disabled. I’d love feedback on this since I need more folks to try it and see if it works as well as I hope it can! Post your feedback in “chat” off your shell.

What We Hardened

Translate-on-Dictate only runs as a post-processing step on the final transcript:

• Live overlay text remains source-language during capture

• Source language follows recognizer locale

• Target language is explicitly selected in Settings

• Settings now filters the target list to language pairs that are actually compatible with the current recognizer locale

• When a supported pair is missing assets, YEN can ask macOS to prepare them while YEN is frontmost in Settings

Failure behavior is deterministic:

• Translation failed -> paste original transcript

• Translation timed out, or the translation availability check stalled -> paste original transcript

• Language pair unsupported, still preparing, or model unavailable -> paste original transcript

• )lder macOS (no Translation framework runtime) -> paste original transcript

We do not block paste on translation success.

We also now cover both the availability lookup and the translation session with the timeout guard, and we cancel translation sessions on timeout or cancellation to avoid overlap under rapid dictate cycles.

Where To Enable It

Open Cmd + , »»» Sounds »»» Speech Setup »»» Translate-on-Dictate.

Choose your target language, then test in any app where YEN dictation already works.

If macOS still needs translation assets for the selected pair, keep YEN frontmost in Settings for the preparation step. Once the pair is ready, dictation uses it. If it is not ready yet, paste still falls back to the original transcript.

Have fun with it!

— 8

There is a particular kind of terminal chaos that shows up the moment you stop demoing and start actually working.

Subscribe now

One pane and/or tab runs the dev server. Another one runs tests. And of course you’ve got one that tails logs. One is a scratch shell you swear is temporary. They all live in the same repo. They all look almost identical. And after a while, your brain is doing bookkeeping the computer should have handled for you.

Mental. Burn. Out.

The tabs help, of course, but tabs are too coarse for this problem and there’s definitely better UX available, right? If your real workflow lives inside a split layout, the unit that needs identity is the pane.

That is why YEN now has Split Labels.

Turn them on in Settings » Workspace » Split Labels. Once enabled, each split gets a small pill at the bottom-left corner using the active terminal theme colors.

Click it directly or open Cmd + Shift + P and run Rename Split Label, and that pane can become anything you want it to be: Server, tests, queue worker, staging ssh, or whatever your future self will thank you for.

Most terminals let you rename tabs. That is useful, but it is not the same thing.

If you work in a three-column layout for client, API, and tests, a tab title does not solve the real problem. The panes are still where the context lives. Split Labels are independent from window titles and tab titles, because pretending those are the same thing just moves the confusion around.

It’s a simple concept:

And the fallback behavior is intentionally boring.

Leave the field blank and YEN goes back to an automatic pane label. That path uses the pane title when it is meaningful, otherwise the working-directory leaf, otherwise Terminal. No weird placeholder nonsense. No permanent rename required just because you wanted a quick label for one session.

But, if you want, it’ll persist.

A lot of terminal UI tricks feel nice right up until you close the app and discover they were only decorative. In YEN, Split Labels are stored with restore state per pane, so they survive tab switches, window restoration, and full session restarts.

If you named the left pane api and the right pane web, YEN should remember that instead of making you rebuild your mental map every morning.

There is also some deliberate restraint here.

The label does not force itself onscreen in every situation. If a pane is too small, if a URL hover preview is visible, or if you are dragging panes around, the label hides. That is not the feature failing. That is the feature refusing to become clutter at exactly the moment the space is tight or the interaction is doing something more important.

No split, no label. Also intentional. UX is how you win minimizing the cognitive load for the user and making the quality of life better. Take a look:

This is one of those details that sounds small until you use it for a week and then wonder why terminals ever stopped at tab titles.

A terminal-first IDE lives or dies on whether it respects working memory. Engineers already keep too much state in their heads. Which pane is production logs. Which one is the migration. Which one is safe to kill. Which one has the REPL with the weird local setup. The terminal should carry more of that load.

That is the philosophy behind Split Labels. Not bigger chrome. Not decoration. Just a small, local-first piece of interface that makes multi-pane work easier to read.

Apparently I needed to build pane name tags because my own split layouts had reached the “which one of you is the test runner again” stage of evolution. Ask me how many times I clicked the wrong pane before admitting tabs were not enough.

If you live in split-heavy terminal layouts, this one should just work.

— 8

A lot of people still do not realize this exists in YEN at all.

Subscribe now

YEN has a built-in community chat system inside the terminal itself. That was already a strange and important line to cross when we first shipped it. We were not adding a side panel to a browser app. We were building what we believe was the first terminal with chat and community built into the product.

That is worth reminding people about, because once chat lives inside a terminal, the bar changes. The terminal is not a casual surface. It is where people debug production issues, inspect logs, move around sensitive files, and work inside a higher-trust environment than most ordinary consumer apps.

So when you say “chat inside a terminal,” the obvious reaction from serious users is not just curiosity. It is caution.

That is a fair reaction.

If chat inside a terminal is sloppy, it is scary. If file attachments inside terminal chat are sloppy, it gets worse fast. So this post is partly about broader file support, but more importantly it is about the security and privacy posture behind it.

First, The Feature Itself

The reason I spent the time building this seem obvious when you first encounter it:

1. It gives me immediate and direct feedback from the community about what they want and features they need. Total win.

2. It inspires me and keeps me motivated. And I can get lonely too.

So, it was built and it’s really, really cool.

And now, I’ve expanded attachment support in YEN Chat beyond the original image and document flow, including CSV, JSON, ICS, EML on top of existingsupport for images and common document formats.

That means people can share a quick export, an API payload sample, a calendar invite, a message thread, a markdown note, or a plain text artifact without leaving the terminal workflow.

That sounds like a convenience feature, but it only works if the delivery path is hardened enough to deserve the trust people place in a terminal. And it is.

I didn’t treat this as “add a few MIME types and move on.” I treated it as a trust-boundary change. That means the file expansion shipped together with private storage, proxy-only delivery, stricter response headers, mediated access paths, and tighter defaults for how different attachment types open.

These are things the user will never see. But, I know they’re air-tight and risk-free. I mean, you shouldn’t share your private keys in chat, but, you can share anything else within reason.

You see? Never share sensitive data! And we’re good. A few things I worked on:

1. Private storage and made files.yen.chat a tightly-controlled delivery path.

2. Direct anonymous storage upload, list, and read paths are denied.

3. Attachment fetches go through the proxy path instead of straight to storage.

4. Upstream fetches use service-role credentials on the server side only.

5. Proxy host and path are tightly bounded.

6. Upstream redirects are rejected.

7. Attachment responses get X-Content-Type-Options: nosniff.

8. Non-image attachments are forced to download with Content-Disposition: attachment and X-Download-Options: noopen instead of rendering inline in the browser.

And, of course, privacy reigns as a surpreme import — I am a cypherpunk, after all. Privacy matters more to me than most people could really understand. So, I extend that to everything that I try to do, especially for folks who count on using this wonderful, beautiful thing that is a Terminal.

You see, security is not only about preventing code execution or bypassing headers. It is also about how much data the system keeps, where identity is bound, and what is exposed by default. YEN Chat is built around mediated access, not direct client trust.

Sender identity is session-bound on the server side and the client uses a local device ID to request a short-lived chat session, and that device ID is treated as a private credential on disk with tightened permissions, including private directory and file modes for its local storage.

Messages and attachments are not meant to live forever. Chat messages age out after 80 hours, and attachments follow the same 80-hour cleanup window. Nothing is kept beyond ~3 days. It’s hard delete only. Let’s go.

So, on the surface it’s a simple “chat” but underneath it’s everything that I’ve learned over 20 years of writing enterprise-grade software, inside a simple frame that can be another place to drop emojis.

Go figure.

— 8