client-core: resolve a bare felis in keymap commands to the running client's sibling CLI #225

New issue

Open

opened 2026-10-21 20:03:44 +09:00 by natsukium · 0 comments

natsukium commented

2026-10-21 20:03:44 +09:00

Owner

Problem

Keymap commands that drive felis itself are expected to keep growing: run pickers over felis sessions …, window launches via background run (#224), felis attach "$FELIS_ORIGIN_SESSION_ID". Every such binding must name the felis CLI. A client launched from Dock/Finder has launchd's minimal PATH, so a bare felis is not found. The workarounds are an upgrade-fragile store path, or a profile path that names whichever felis the profile has, not necessarily the build that is running.

Direction (needs its own design)

Have a bare felis in a keymap argv name the CLI that belongs to the running client. The precedent exists: the client finds its daemon beside its own executable before consulting PATH (sibling_daemon in crates/felis-client-core/src/spawn.rs), "so it runs the matching build instead of whatever a stray PATH offers". The macOS bundle already ships felis next to felis-client and felis-daemon in Contents/MacOS (nix/make-macos-app.sh --cli).

This is deliberately narrower than general PATH resolution, which #224 rejected because it re-implements the OS executable lookup. Here there is no PATH walk: either the sibling binary exists, or the argv is passed through unchanged.

Open questions:

Surface. Rewrite argv[0] when it is exactly felis; or put the client's own directory on the command's PATH (this exposes felis-client / felis-daemon too, and in a shared bin directory it reorders every tool); or export the path as a variable (sh -c only).
Children. Should the command's children (a script calling felis sessions …) also reach the sibling?
Platform layout. The macOS bundle, a Linux bin/, Windows, and a cargo build tree where no sibling felis exists.
Scope. Whether this is the first step of a "fixed point": a bare felis that also inherits the window's --socket / --config / --host.

Run principle-check before any code.

## Problem Keymap commands that drive felis itself are expected to keep growing: `run` pickers over `felis sessions …`, window launches via background `run` (#224), `felis attach "$FELIS_ORIGIN_SESSION_ID"`. Every such binding must name the felis CLI. A client launched from Dock/Finder has launchd's minimal `PATH`, so a bare `felis` is not found. The workarounds are an upgrade-fragile store path, or a profile path that names *whichever* felis the profile has, not necessarily the build that is running. ## Direction (needs its own design) Have a bare `felis` in a keymap argv name the CLI that belongs to the running client. The precedent exists: the client finds its daemon beside its own executable before consulting `PATH` (`sibling_daemon` in `crates/felis-client-core/src/spawn.rs`), "so it runs the *matching* build instead of whatever a stray PATH offers". The macOS bundle already ships `felis` next to `felis-client` and `felis-daemon` in `Contents/MacOS` (`nix/make-macos-app.sh` `--cli`). This is deliberately narrower than general PATH resolution, which #224 rejected because it re-implements the OS executable lookup. Here there is no PATH walk: either the sibling binary exists, or the argv is passed through unchanged. Open questions: - **Surface.** Rewrite argv[0] when it is exactly `felis`; or put the client's own directory on the command's `PATH` (this exposes `felis-client` / `felis-daemon` too, and in a shared `bin` directory it reorders every tool); or export the path as a variable (`sh -c` only). - **Children.** Should the command's children (a script calling `felis sessions …`) also reach the sibling? - **Platform layout.** The macOS bundle, a Linux `bin/`, Windows, and a `cargo build` tree where no sibling `felis` exists. - **Scope.** Whether this is the first step of a "fixed point": a bare `felis` that also inherits the window's `--socket` / `--config` / `--host`. Run `principle-check` before any code.

natsukium added the

Area/client-core

Kind/Enhancement

labels

2026-10-21 20:04:02 +09:00

natsukium referenced this issue

2026-10-21 20:04:18 +09:00

client: run a keymap command in the background without a transient session #224

natsukium referenced this issue

2026-10-21 21:31:18 +09:00

client: run a keymap command in the background without a transient session #227