fix(ipc): the client is found on ARM too, and a relative path is refused instead of run

Conversation 0 Commits 2 Files Changed 4

+277 -39

2 Commits

Author	SHA1	Message	Date
enricobuehlerandClaude Opus 5	7d3654ad41	docs: don't name a release that doesn't exist yet CI / build (pull_request) Successful in 2m4s Details CI / publish (pull_request) Skipped Details The /tmp and log-page notes referenced punktfunk 0.23.1 as the version carrying the fix. 0.23.0 is the latest tag and the next number isn't decided, so that claim could simply be wrong on arrival. Phrase both against 0.23.0, which is a fact. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 16:00:39 +02:00
enricobuehlerandClaude Opus 5	1dc5ac9b25	fix(ipc): the client is found on ARM too, and a relative path is refused instead of run Two bugs in how the Linux/macOS backend decides which VirtualHere binary to run, both reported by a user whose plugin could not use a client that was installed and working. `KNOWN_BINARIES` has listed four architecture variants since the first commit, but `resolveBinary` only ever returned the first of them. On anything that is not x86_64 the plugin therefore asked for `vhclientx86_64`, got ENOENT, and told the operator to install the client they already had. It now probes PATH across every name and hands back the absolute path it found. The absolute-path rule was documented in this file and in the README from the start — "anything else is rejected rather than executed" — and was never implemented: whatever the operator typed went straight to execFile. So a bare name silently resolved out of the runner's PATH, which is not the PATH of the shell they tested in and which they cannot see. It is now enforced, and says which of the two mistakes was made. Resolution failure is carried to the first send as an ordinary VhIpcError rather than failing the layer, so the plugin stays up and the Diagnostics tab (and `doctor`) can render the reason with its remedy — losing the console page that explains a missing client would be a poor trade for a client that is missing by default. Also records, here and in the README, that the `/tmp` FIFOs this backend depends on were invisible to the plugin runner until punktfunk 0.23.1: the unit set PrivateTmp=yes, so the binary launched and could never reach the daemon behind it. That is the shape of the original report — works in a shell, fails from the plugin, and no config change helps. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-03 15:19:32 +02:00

Author

SHA1

Message

Date

enricobuehlerandClaude Opus 5

7d3654ad41

docs: don't name a release that doesn't exist yet

CI / build (pull_request) Successful in 2m4s

Details

CI / publish (pull_request) Skipped

Details

The /tmp and log-page notes referenced punktfunk 0.23.1 as the version carrying
the fix. 0.23.0 is the latest tag and the next number isn't decided, so that
claim could simply be wrong on arrival. Phrase both against 0.23.0, which is a
fact.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-03 16:00:39 +02:00

enricobuehlerandClaude Opus 5

1dc5ac9b25

fix(ipc): the client is found on ARM too, and a relative path is refused instead of run

Two bugs in how the Linux/macOS backend decides which VirtualHere binary to
run, both reported by a user whose plugin could not use a client that was
installed and working.

`KNOWN_BINARIES` has listed four architecture variants since the first commit,
but `resolveBinary` only ever returned the first of them. On anything that is
not x86_64 the plugin therefore asked for `vhclientx86_64`, got ENOENT, and told
the operator to install the client they already had. It now probes PATH across
every name and hands back the absolute path it found.

The absolute-path rule was documented in this file and in the README from the
start — "anything else is rejected rather than executed" — and was never
implemented: whatever the operator typed went straight to execFile. So a bare
name silently resolved out of the *runner's* PATH, which is not the PATH of the
shell they tested in and which they cannot see. It is now enforced, and says
which of the two mistakes was made.

Resolution failure is carried to the first send as an ordinary VhIpcError rather
than failing the layer, so the plugin stays up and the Diagnostics tab (and
`doctor`) can render the reason with its remedy — losing the console page that
explains a missing client would be a poor trade for a client that is missing by
default.

Also records, here and in the README, that the `/tmp` FIFOs this backend depends
on were invisible to the plugin runner until punktfunk 0.23.1: the unit set
PrivateTmp=yes, so the binary launched and could never reach the daemon behind
it. That is the shape of the original report — works in a shell, fails from the
plugin, and no config change helps.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-03 15:19:32 +02:00

fix(ipc): the client is found on ARM too, and a relative path is refused instead of run #1