Installer auto-detects binaries for the invoking user, not the configured service_user

[JacobStephens2]

Problem

install.sh determines the account that will run Harnesses in SERVICE_USER, but find_user_bin probes SUDO_USER and that user's home. write_auto_harness can therefore record an operator-owned binary directory in bin= even when --user <service-user> selects a different execution account.

Personal installs hide the mismatch because the invoking user and execution user are the same. On a shared host, the generated Harness can either fail because the service user cannot traverse the operator's home or quietly depend on one operator's mutable installation. AGY exposed this existing gap, but it applies to every auto-detected command.

Scope

Resolve auto-detected binaries for the configured launch identity in SERVICE_USER. Preserve same-user behavior and system-wide binary detection. When the invoking user and service user differ and a binary exists only for the invoker, skip the live Harness and explain how to install the CLI for the service user or configure the Harness explicitly.

Apply one policy to Claude, Codex, Grok, Kimi, AGY, and Bash. Preserve existing Harness files byte-for-byte. Keep caller-scoped uses of SUDO_USER, including the user-local va link and source build, unchanged.

Acceptance criteria

• Same-user installation retains current user-local and system-path detection.
• A binary found only under a different invoking user's home does not create a live Harness for SERVICE_USER.
• A binary available to the service user creates a Harness whose bin= names the resolved directory.
• System-wide binaries remain detectable for either installation shape.
• A skipped binary message names both identities and gives a concrete remedy.
• Existing harnesses.d/<name>.conf files remain byte-identical, and --no-auto-harness is unchanged.
• A regression test covers different invoking and service-user identities without relying on a developer's actual home or installed agents.
• README installer wording says auto-detection is evaluated for the account that runs the Harness.

Out of scope

• Installing or copying an agent CLI.
• Changing home-directory permissions.
• Runtime PATH fallback or per-caller child-environment routing from Shared service-user hosts need a supported per-caller child-environment route #90.
• AGY-specific command, permission, or conversation behavior.

This issue does not block AGY Harness support. A shared host can install AGY for its service user and configure that Harness explicitly.

[JacobStephens2]

The Selector has now dispatched this issue 2 times. The last Run was cut short by agent-failed.

The retry budget is 2 attempts per Handover, and it is now spent, so the label has been swapped to ready-for-human. No further Run will be started for this issue: a third dispatch is refused whatever the label says.

What this attempt left behind: #109

If the failure was transient, or you have changed something that fixes it, re-apply ready-for-agent: that is a fresh Handover with a fresh retry budget.

Posted by the Selector. Deterministic code, not an agent - no model wrote this and none read the issue.