Warn on risky service install contexts and make service status show the pinned runtime

[geekforbrains]

Summary

operator service install already does the core runtime work correctly:

• it pins an operator executable
• it embeds the current PATH into the launchd/systemd service definition

What is still missing is install-time guardrails and clear runtime visibility.

Problem

Operator is a long-lived local agent that runs:

• shell commands
• skill scripts
• scheduled job hooks

That makes the background service environment part of the product, not an internal detail.

Today service install writes the service definition with no install-context summary and no warnings. Users can install from contexts like:

• a project-local virtualenv
• a conda environment
• a direnv shell
• a nix shell
• a pyenv shim-based selection
• a shell with project-local .venv/bin early in PATH

Some of those are intentional. Some are accidental. The problem is that the user gets no signal either way.

Debugging is also weaker than it should be. service status is already a debug-oriented command and can be noisy, but it currently does not show the pinned runtime details that matter most when a service cannot find tools:

• pinned operator executable path
• Python interpreter path
• pinned service PATH

Goal

Keep the current service model, but make it explicit and debuggable.

The model should remain:

• service install pins the executable it will start
• service install embeds the current PATH
• Operator does not re-enter the user’s login shell at runtime
• when the desired executable or PATH changes, the fix is to reinstall the service

Proposed changes

1. Show an install-context summary before writing the service

Print a short summary during operator service install:

• resolved operator executable path
• Python interpreter path for that executable
• current PATH
• whether the install appears to be coming from a virtualenv
• notable shell markers if present:
  • CONDA_PREFIX
  • DIRENV_DIR
  • IN_NIX_SHELL

This should be concise, but visible every time.

2. Warn only on contexts that are likely to be fragile

Warn when the pinned executable or PATH looks transient or shell-local, for example:

• executable lives under a virtualenv
• PATH contains project-local .venv/bin
• conda / direnv / nix shell markers are present
• executable appears to be a shim rather than a direct install target

The warning should explain the consequence plainly:

The background service will keep using this executable selection and PATH until you reinstall it.

3. Make service status print the pinned runtime details

service status should always show the installed runtime details alongside running state.

At minimum:

• pinned executable path
• Python interpreter path
• pinned service PATH

No separate inspect command is needed. service status is already a noisy, debug-oriented command, so this information belongs there.

Non-goals

• no login-shell wrapping at runtime
• no fallback path builder
• no automatic environment import magic
• no attempt to make shell functions like nvm or conda activate available inside subprocesses

Why this is worth doing

This is a UX and debuggability issue around an already-correct runtime model.

The missing piece is not “make services smarter.” The missing piece is:

• warn when the install context looks accidental
• make the pinned runtime obvious in service status

That keeps the system simple while making background-service behavior much easier to understand and support.

Acceptance criteria

• operator service install prints a concise runtime summary before installing
• risky install contexts produce a targeted warning
• operator service status prints the pinned executable, Python path, and service PATH
• docs explain that reinstalling the service is the fix when the desired executable or PATH changes