readonly remote deploy-state checks need a coily wrapper #58

Open
opened 2026-05-23 20:54:04 +00:00 by coilysiren · 0 comments
Owner

Originally filed by @coilysiren on 2026-05-05T02:32:53Z - https://github.com/coilysiren/coily/issues/48

Problem

There's a recurring shape that currently has no good entry point: "has my last push to repo X reached host Y yet, and is the service healthy?"

Concrete instance that surfaced this: sirens-discord-ops deploys via an on-host systemd auto-update timer (5-min poll of origin/main, rebuild + restart on diff). After a git push, the natural follow-up is to poll until the new SHA is live before testing the change. The mechanically obvious way to do that is ssh kai-server 'git rev-parse HEAD && systemctl status ...' - readonly, no state change, allow-listed via Bash(ssh:*) in settings.

But the Claude Code harness treats any ssh <prod-host> invocation as a "production remote shell" action and blocks it above the allow-list. That's the right default - bare SSH is too coarse a hammer to whitelist - but it leaves no path for the readonly polling case other than asking for one-off authorization every time.

Why this belongs in coily

The wrapper-everything principle: every privileged or production-touching op routes through coily so it inherits the audit + gate discipline, and the harness can trust the wrapper's narrower surface instead of the SSH primitive. Readonly remote inspection has been ad-hoc'd via raw SSH because no wrapper exists yet - same gap that coily aws ssm and coily gaming eco filled for their domains.

Recurring shapes that would use this

  • Post-push: "is sirens-discord-ops on $SHA yet on kai-server?"
  • Post-push: "is the k3s homelab on $SHA yet?" (during upgrades)
  • "is service X up on host Y, and what's its last restart time?"
  • "tail the last N lines of journalctl for unit Z" (readonly forensics)

All of these are bounded, readonly, and want the same audit trail as a write op - they just don't change anything.

Out of scope (intentionally)

Not prescribing the surface here. The architectural call - subcommand layout, how hosts are declared, whether this fronts SSH directly or goes through Tailscale serve / a sidecar / etc. - is the follow-up.

_Originally filed by @coilysiren on 2026-05-05T02:32:53Z - [https://github.com/coilysiren/coily/issues/48](https://github.com/coilysiren/coily/issues/48)_ ## Problem There's a recurring shape that currently has no good entry point: **"has my last push to repo X reached host Y yet, and is the service healthy?"** Concrete instance that surfaced this: `sirens-discord-ops` deploys via an on-host systemd auto-update timer (5-min poll of `origin/main`, rebuild + restart on diff). After a `git push`, the natural follow-up is to poll until the new SHA is live before testing the change. The mechanically obvious way to do that is `ssh kai-server 'git rev-parse HEAD && systemctl status ...'` - readonly, no state change, allow-listed via `Bash(ssh:*)` in settings. But the Claude Code harness treats any `ssh <prod-host>` invocation as a "production remote shell" action and blocks it above the allow-list. That's the right default - bare SSH is too coarse a hammer to whitelist - but it leaves no path for the readonly polling case other than asking for one-off authorization every time. ## Why this belongs in coily The wrapper-everything principle: every privileged or production-touching op routes through coily so it inherits the audit + gate discipline, and the harness can trust the wrapper's narrower surface instead of the SSH primitive. Readonly remote inspection has been ad-hoc'd via raw SSH because no wrapper exists yet - same gap that `coily aws ssm` and `coily gaming eco` filled for their domains. ## Recurring shapes that would use this - Post-push: "is sirens-discord-ops on $SHA yet on kai-server?" - Post-push: "is the k3s homelab on $SHA yet?" (during upgrades) - "is service X up on host Y, and what's its last restart time?" - "tail the last N lines of journalctl for unit Z" (readonly forensics) All of these are bounded, readonly, and want the same audit trail as a write op - they just don't change anything. ## Out of scope (intentionally) Not prescribing the surface here. The architectural call - subcommand layout, how hosts are declared, whether this fronts SSH directly or goes through Tailscale serve / a sidecar / etc. - is the follow-up.
coilysiren added
P4
and removed
P3
labels 2026-05-31 06:59:47 +00:00
Sign in to join this conversation.
No labels
P0
P1
P2
P3
P4
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
coilyco-bridge/coily#58
No description provided.