The shape is always the same: Claude Code on the Mac, Codex on a build box, something else on a server you log into twice a week. Every one of them stops before it deploys, deletes or installs, and waits for a yes. The yes takes two seconds. Working out who is waiting, and where, is what ate my evenings.

The obvious discipline is a tmux session per machine, one terminal per project, and a habit of tailing the right scrollback. That holds until the third machine, and then you are the router. You alt-tab, you read a wall of output to see whether the agent is stuck or just quiet, you SSH in to check.

None of that is a complaint about Herdr. Herdr already knows which agent is working, waiting, done or idle, and it keeps them all alive whether or not anyone is looking. What I wanted was narrower: one Mac window with every agent in it, on every machine, and two keys to the one that needs me.

So I built Shepi for Herdr. It is a native Mac client for Herdr: every agent in a real terminal, on this Mac or your servers, with the one that needs you in amber.

It does not replace Herdr. Herdr keeps running your agents and Shepi is a window onto it. Quit Shepi and nothing stops; open it again and every space, tab and agent you already had is exactly where you left it.

Amber means exactly one thing

When an agent stops to ask, it turns amber in three places at once: the sidebar, its pane header and the status line. A card shows the command it wants to run, when the agent says so. A banner reaches you even with the sidebar folded away with ⇧⌘1, and you hear Herdr's own sound, at the moments Herdr would play it, from every machine.

Then it is the prefix and a. ⌃B a lands you on the next agent that needs you, whichever machine it is on. Review on the card does the same thing with the mouse.

Amber means one thing in Shepi: something needs you. That is the whole colour language.

The agent can ask you with buttons, not just a menu

Most of the time an agent's question is a numbered menu in a wall of terminal output, and the cheap thing to do is hit 1 and hope. In Shepi an agent can ask you properly:

shepi-agent ask "Deploy to staging?" --options Deploy,Wait

It arrives like any agent that needs you, and your click goes straight back to it as the answer. The same small plugin lets an agent open a page or a file on your Mac, report its progress under its own name in the sidebar ("Step 3 of 7 · migrating"), and open a pane beside itself to run tests or a dev server, marked as opened by it and never taking your keyboard. On your servers too.

Shepi installs that plugin on every machine it connects to, and Claude Code, Codex, Cursor, OpenCode, Gemini CLI, Copilot CLI, Amp and Grok Build pick the skill up by themselves. Any other agent needs one line in its instructions. Agents ask, show, report and arrange; they never type into a pane or click for you.

Your servers are in the same sidebar

Add any machine you reach over SSH from the sidebar or Settings › Machines, as you@server or a host from ~/.ssh/config. Herdr's own machine setup runs in a terminal inside Shepi, so host keys and passphrases stay in your hands.

It joins as its own group, and every space shows how many agents need you, are working, are done or idle. Agents on a server keep going even while this Mac sleeps.

When a server prints http://localhost:5173, ⌘-click it. Shepi forwards that port over your SSH connection and opens the page here, on another port if 5173 is taken, and the status line says which.

Five letters to a pane on another machine

⌘F searches agents, spaces, panes, machines and the recent output of every pane, local and over SSH. Type a word or two in any order; separators do not matter and first letters work, so fat finds fix-flaky-auth-test. One typo in a longer word is forgiven. Land on output and ⌘G steps through the matches.

⌘E lists the panes you used last, newest first, with the one you just left already selected. ⌘E, Return, and you are back in it.

Then the terminal chores are just gone

None of these are the reason I built it, and all of them are the reason I stopped going back.

Paste a screenshot or drop files onto a pane. On this Mac the paths are pasted; on a server Shepi copies them over SSH first, so Claude Code sees the image as if it were local, up to 32 MB at a time. The prefix and d shows every file changed since the last commit, side by side or in one column, on this Mac or a server, and only shows: it never stages or edits.

The pane your keys go to is the lighter card and the only one with a blinking cursor, and its header names the agent in it, while every other pane stays at full brightness. Drag a pane by its header and the layout shows where it will land before you let go; drop it on another tab and the program inside never stops running. The prefix and = evens out every pane in the tab, the prefix and z takes one full-window and puts the layout back, and a macro on any key of your choosing can type /model, press Return, wait for "Select model", then two more keys into the pane you are in, on this Mac or a server.

The keys are Herdr's, read live from its config. Shepi never edits that file, and change one there and Shepi follows. Almost everything also has a mouse equivalent, and every tooltip names its key.

Step away for six hours

Leave Shepi open and walk away. Every agent that needed you, finished or asked a question meanwhile waits in the inbox next to Find, one entry per pane, until you look at that pane. The Dock icon shows how many and right-clicking it lists them.

Quit the window instead and it works out the same. Herdr keeps your agents running, and on your servers they keep going even while the Mac sleeps. Reopen Shepi and everything is where you left it. If the connection dropped, the status line says how many panes changed while you were gone.

What it is, and what it isn't

• It works with Claude Code, Codex, OpenCode, Gemini CLI, Cursor, Copilot CLI and anything else that runs in a terminal. Every agent Herdr recognises shows its state; the common ones show their own mark.
• No analytics, no crash reports, and no Shepi account to create.
• macOS 14 or later, Apple silicon and Intel, notarized by Apple. Herdr 0.9.3 or later; if it is missing, Shepi shows you the one-line install command.
• Two honest limits: a screenshot pasted into a pane on a server is a file there, not a picture on your screen, and a pane can move between tabs of one space, not between machines.
• An independent client built on Herdr's public interface. Not made by the Herdr project, and not affiliated with it.

https://shepi.app/

If your agents are spread across a Mac and two servers, how do you keep track of which one is waiting on you without checking all three?

https://apps.apple.com/us/app/your-app/id1232780281

That /us/ is the problem. App Store web links carry a two-letter country code, because Apple runs a separate store (a "storefront") for each country. Someone in Japan who taps a /us/ link is looking at the US store. And if your app isn't sold in their country at all, they hit Apple's "This app is not available in your country or region" message instead of your app.

Making a separate link for every country isn't realistic. You'd need to know where each reader is before they click. So the link has to work it out at click time.

The useful fact: the app ID never changes

Every app has a numeric ID, the id1232780281 part. It's the same in every country. The only thing that changes between storefronts is the country code:

apps.apple.com/us/app/id1232780281
apps.apple.com/jp/app/id1232780281
apps.apple.com/de/app/id1232780281

So if you know the visitor's country and you know the app is sold there, you can build the right URL yourself.

Step 1: where is the visitor?

If your code runs on Cloudflare Workers, you get this for free. Cloudflare attaches the visitor's country to every request as request.cf.country, an ISO code like JP. Two values need care: XX means unknown and T1 means Tor. Treat both as "no country".

function normalizeCountry(raw: unknown): string | null {
  if (typeof raw !== "string" || !/^[A-Za-z]{2}$/.test(raw)) return null;
  const cc = raw.toLowerCase();
  return cc === "xx" || cc === "t1" ? null : cc;
}

When the country is unknown, the safest redirect is Apple's country-less link, https://apps.apple.com/app/id<ID>, and Apple picks the store.

Step 2: is the app sold there?

Apple has a public lookup endpoint (the old iTunes Search API) that answers this:

https://itunes.apple.com/lookup?id=1232780281&country=jp

If the app is in that storefront you get resultCount: 1 plus its name and icon. If it isn't, you get resultCount: 0. No key needed.

The endpoint is rate-limited, so don't call it on every click. On Workers you can cache the fetch at the edge:

const res = await fetch(url, { cf: { cacheTtl: 86400, cacheEverything: true } });

A day of caching means Apple only gets asked about each app and country pair occasionally. The trade-off: when an app launches in a new country, detection can lag by up to a day.

Step 3: when it isn't sold there

Now you need a fallback. Most apps are in the US store, so check that first, then walk a list of other large storefronts (UK, Canada, Australia, Germany, France, Japan and so on) until one says yes.

On a computer or Android phone, you can just redirect to that store's page. The visitor sees the app, its screenshots, its description.

The iPhone catch

This is the part that surprised me. On iPhone and iPad, App Store links open in the App Store app, and the App Store app can only show the store for the account's own country. So redirecting a visitor in, say, Brazil to the /us/ page doesn't show them the US page. It ends in the same "not available" message you were trying to avoid.

The only honest fix is to not redirect. Instead, show a small page with the app's icon and name (both come from the lookup response) and a button to the store that has it. At least the visitor sees which app you meant and where it's sold. It's less magic than a redirect, but it doesn't dead-end.

One more failure case

If Apple's endpoint is down or returns an error, don't show an error page. Send the visitor to their own country's page. Most of the time the app is sold there anyway.

Putting it together: Hither

I wrapped all of this into a small free tool called Hither. You paste any App Store link (from any country) or a bare app ID, and you get:

hither.link/1232780281

The link holds only the app ID, so there's no database. The same app always gets the same link, links don't expire, and nobody can change where a link goes, because everything else comes from Apple at click time. There's no account. You can even make your link before launch, using the Apple ID from your app's App Information page in App Store Connect, and put it on your landing page ahead of time.

Run your own copy

The code is on GitHub under the MIT license. It's a single Cloudflare Worker, and the Apple-specific bits live in one file (src/apple.ts) while the routing decision is pure, tested logic (src/decide.ts).

npm install
npm test
npm run dev

To deploy to your own domain:

npx wrangler login
CLOUDFLARE_ACCOUNT_ID=your-account-id npm run deploy

Change the domain in wrangler.toml, public/robots.txt and public/sitemap.xml first. On Cloudflare's free plan a Worker handles 100,000 requests a day, and going over makes requests fail until the daily reset instead of producing a bill.

Ideas on the list: Google Play links, custom short names (with a way to prove you own the app), and a QR code per link. If you've hit other edge cases with App Store links across countries, I'd like to hear about them in the comments.

Originally published on dev.to.