feat: say which machine commands actually run on #6

Closed

airaneel wants to merge 0 commits from say-where-commands-run into main

airaneel commented

2026-08-16 15:05:36 +03:00

Owner

Closes the audit item «Написать в описании run_command, что команда идёт ВНУТРИ контейнера babash, а не на хосте» — by stating the fact rather than documenting it.

The problem

A model asked to check "the server" cannot tell whether babash is the shell of the machine it means. Over stdio it usually is; deployed it usually is not. In babash-remote, docker ps lists the container's own view and systemctl talks to nothing — so commands run, exit zero, and describe a machine nobody asked about. Wrong answers, confidently delivered.

The fix

babash_initialize now reports hostname and containment, observed at runtime.

Once, not per reply — it is a property of the server and cannot change mid-conversation.
Observed, not configured — an env var describing the deployment is a second copy of the truth, free to go stale the moment the container moves. There was one, BABASH_SERVER_INSTRUCTIONS; the code stopped reading it in fb67093 and the deployed stack still sets it, silently doing nothing since. Worth removing from the stack separately.

run_command's description no longer opens with a bare "Execute a shell command" either — it names where that happens and points at babash_initialize for which machine this is.

The detail that matters

Marker files are checked before the cgroup, and that order is the whole trick. babash-remote runs with pid: host, so pid 1 is the host's init and /proc/1/cgroup reads 0::/../../init.scope — a host cgroup, read from inside a container. Detection leaning on that line alone would be confidently wrong for the one deployment this matters most for.

Verified by reading all three signals inside the running container: /.dockerenv True, /run/.containerenv False, cgroup host-looking.

Verification

119 passed, mypy --strict and ruff clean. The decision is a pure function over three readings, so both directions are tested without needing a container to run in: no false positive on a laptop or on macOS (where the file does not exist), and no silence inside one.

🤖 Generated with Claude Code

Closes the audit item *«Написать в описании run_command, что команда идёт ВНУТРИ контейнера babash, а не на хосте»* — by stating the fact rather than documenting it. ## The problem A model asked to check "the server" cannot tell whether babash is the shell of the machine it means. Over stdio it usually is; deployed it usually is not. In babash-remote, `docker ps` lists the container's own view and `systemctl` talks to nothing — so commands run, exit zero, and describe a machine nobody asked about. Wrong answers, confidently delivered. ## The fix `babash_initialize` now reports hostname and containment, observed at runtime. - **Once**, not per reply — it is a property of the server and cannot change mid-conversation. - **Observed**, not configured — an env var describing the deployment is a second copy of the truth, free to go stale the moment the container moves. There was one, `BABASH_SERVER_INSTRUCTIONS`; the code stopped reading it in fb67093 and **the deployed stack still sets it**, silently doing nothing since. Worth removing from the stack separately. `run_command`'s description no longer opens with a bare "Execute a shell command" either — it names where that happens and points at `babash_initialize` for which machine this is. ## The detail that matters Marker files are checked **before** the cgroup, and that order is the whole trick. babash-remote runs with `pid: host`, so pid 1 is the host's init and `/proc/1/cgroup` reads `0::/../../init.scope` — a host cgroup, read from inside a container. Detection leaning on that line alone would be confidently wrong for the one deployment this matters most for. Verified by reading all three signals inside the running container: `/.dockerenv` True, `/run/.containerenv` False, cgroup host-looking. ## Verification `119 passed`, `mypy --strict` and `ruff` clean. The decision is a pure function over three readings, so both directions are tested without needing a container to run in: no false positive on a laptop or on macOS (where the file does not exist), and no silence inside one. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

airaneel added 1 commit

2026-08-16 15:05:36 +03:00

feat: say which machine commands actually run on

build-image / build (push) Successful in 29s

Details

26727a0c12

A model asked to check "the server" has no way to know whether babash is the
shell of the machine it means. Over stdio it usually is. Deployed it usually is
not: babash-remote is a container, so `docker ps` in there lists the container's
own view and `systemctl` talks to nothing, while the host the question was about
sits one namespace away.

Nothing in the tool surface said so, and the cost was not confusion but wrong
answers delivered confidently — commands ran, exited zero, and described a
machine nobody had asked about.

babash_initialize now states it once, from what the process can observe:
hostname, and whether this is a container. Once rather than per reply, because
it is a property of the server and cannot change mid-conversation; and observed
rather than configured, because an env var describing the deployment is a second
copy of the truth, free to go stale the moment the container moves. There was
such a var — BABASH_SERVER_INSTRUCTIONS — and the deployed stack still sets it,
though the code stopped reading it in fb67093. It has been silently doing
nothing since.

run_command's description no longer opens with a bare "Execute a shell command"
either; it names where that happens and points at babash_initialize for which
machine this is.

The marker files are checked before the cgroup, and that order is the whole
trick. babash-remote runs with `pid: host`, so pid 1 is the host's init and
/proc/1/cgroup reads `0::/../../init.scope` — a host cgroup, read from inside a
container. Detection leaning on that line alone would be confidently wrong for
the one deployment this matters most for. Verified by reading all three signals
inside the running container.

The decision is a pure function over three readings, so both directions are
tested without needing a container to run in: no false positive on a laptop or
on macOS (where the file does not exist), and no silence inside one.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

airaneel closed this pull request

2026-08-16 15:07:33 +03:00

build-image / build (push) Successful in 29s

Details

Pull request closed

This pull request cannot be reopened because the branch was deleted.

No reviewers

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

airaneel/babash!6

No description provided.

Rows
Columns