[bug]:bundled zellij not resolved as expected

[suraj-markup]

Summary

Steps to reproduce

1. ran npx yyork <folder path>
2. got this on web

Expected behavior

it should not come

Actual behavior

no issue should come

Screenshots / recordings

No response

Area

Terminal / renderer

Environment

No response

Root cause / notes (optional)

No response

[suraj-markup]

00:40:44.253 INFO terminal attach strategy strategy=direct

yyork
➜ server http://127.0.0.1:7331
➜ store /Users/suraj/.yyork/state.db

00:40:47.706 WARN failed to start terminal attach session_id=s0eewr error="start terminal command "zellij": exec: "zellij": executable file not found in $PATH"
00:41:31.030 WARN failed to start terminal attach session_id=s0eewr error="start terminal command "zellij": exec: "zellij": executable file not found in $PATH"
00:41:39.845 WARN failed to start terminal attach session_id=s0eewr error="start terminal command "zellij": exec: "zellij": executable file not found in $PATH"

[suraj-markup]

That error is exactly what it says: your app is trying to launch a terminal-attach session by running the zellij binary, and zellij isn't installed (or isn't on the $PATH the process sees).

exec: "zellij": executable file not found in $PATH

exec.LookPath("zellij") failed → Go's exec.Command couldn't find the executable → the terminal attach session never starts. This is almost certainly your AO Go daemon's terminal-attach feature, which shells out to zellij (https://zellij.dev) (a terminal multiplexer, like tmux) to host the session.

Two things could be true:

1. zellij genuinely isn't installed on that machine. Fix:
   brew install zellij # macOS
2. Then confirm it's found:
   which zellij
3. zellij IS installed, but the daemon's $PATH doesn't include it. This is common when the process is launched by a GUI app (Electron/launchd) rather than your interactive shell — GUI-launched processes on macOS often get a minimal $PATH (/usr/bin:/bin:/usr/sbin:/sbin) that excludes Homebrew's /opt/homebrew/bin. So it works when you run it from your terminal but fails when launched by the app.

To tell which one you're hitting, run:
which zellij && echo $PATH

• If which zellij finds nothing → it's case [bug]: wterm renderer breaks box-drawing borders (blocked on upstream wterm#52) #1, install it.
• If it's found (e.g. /opt/homebrew/bin/zellij) but the daemon still fails → it's case [bug]: terminal failing to start #2, a PATH problem.

For case #2, the fixes (in order of preference):

• Make the daemon resolve zellij with an absolute path, or extend the child process's PATH env to include /opt/homebrew/bin before spawning.
• Or symlink it somewhere always on PATH: sudo ln -s $(which zellij) /usr/local/bin/zellij.

Which is it — does which zellij return anything? If you tell me, I'll point you at the right fix (and if it's the daemon PATH issue, I can show you where AO likely spawns the zellij command so you can patch it properly).

[suraj-markup]

Fully checked now. Here's the verdict:

The bundled zellij is completely fine — executable (rwxr-xr-x), not quarantined (only com.apple.provenance, no com.apple.quarantine), and it runs: zellij 0.44.3. It sits right next to the yyork binary in the same bin/ folder:

.../node_modules/@yyopc/yyork-darwin-arm64/bin/
├── yyork ← the daemon
└── zellij ← the multiplexer it wants to launch

So the binary is healthy. The bug is purely that yyork spawns zellij by bare name and relies on $PATH, but its own bin/ dir isn't on $PATH — so exec.LookPath fails even though zellij is literally sitting beside it. That's a bug in yyork (it should resolve zellij relative to its own executable via os.Executable()), not something wrong on your end.

Fastest fix to unblock yourself right now — install a real zellij so it's on $PATH:
brew install zellij
Your $PATH already includes /opt/homebrew/bin, so yyork's LookPath("zellij") will immediately find it. This is the most durable option because the npx cache path (_npx/c085c66b...) is a hashed, throwaway directory that changes on every reinstall.

If you don't want to install anything, symlink the bundled one onto a PATH dir (works until yyork reinstalls to a new cache hash):
ln -sf "/Users/suraj/.npm/_npx/c085c66b772fc8ac/node_modules/@yyopc/yyork-darwin-arm64/bin/zellij" /.local/bin/zellij
(/.local/bin is already on your PATH.)

I'd go with brew install zellij — cleanest and survives yyork updates. Want me to run it?

✻ Brewed for 1m 20s

❯ how to fix it in yyork

You'd fix it in yyork's Go source, in the spot where it spawns the terminal-attach command. I don't have the yyork source in this session (we only have the compiled binary from the npx cache), so I can't edit the exact file — but here's precisely what to change.

Find the spawn call. Grep the yyork repo for where it launches zellij:
grep -rn '"zellij"' .
grep -rn 'terminal attach' .
grep -rn 'exec.Command' .
You're looking for something like:
cmd := exec.Command("zellij", args...)
That bare "zellij" is the bug — Go's exec does a $PATH lookup on any name wit own bin/ isn't on $PATH.
The fix — resolve zellij relative to the yyork binary, since they're bundled dir:
// resolveZellij returns the path to the zellij binary shipped
// alongside the yyork executable, falling back to $PATH. func resolveZellij() string {
exe, err := os.Executable() if err == nil {
// yyork and zellij live in the same bin/ dir candidate := filepath.Join(filepath.Dir(exe), "zellij")
if fi, err := os.Stat(candidate); err == nil && !fi.IsDir() { return candidate
} }
// fall back to PATH (covers brew install zellij etc.) if p, err := exec.LookPath("zellij"); err == nil {
return p }
return "zellij" // last resort; will error clearly if truly missing }
Then at the spawn site:
cmd := exec.Command(resolveZellij(), args...)
Because resolveZellij() returns a path containing a separator, Go skips the $PATH lookup entirely and runs the bundled binary directly.
Why this is the right fix (not just prepending to PATH): - os.Executable() follows the real binary location, so it works no matter whe(including that hashed _npx/c085c66b... cache dir).

It still honors a system-installed zellij as a fallback. - It fixes it for every user of the package, not just your machine.
One thing to verify while you're in there: on macOS, GUI/Electron-launched dahich is likely why this surfaced now. If yyork spawns other external tools bybare name too (git, etc. — and note memory has a spawn git ENOENT entry for AO), they'll have the same latent bug. Worth grepping exec.Command( broadly and giving bundled tools the same os.Executable()-relative treatment.
If you point me at the yyork repo path (or clone it somewhere I can reach), Iand write the patch directly.