[Bug bounty] workload.logs returns ok:true with no stopped indicator for a stopped workload, contradicting workload.status

[mobster31]

Eligibility

• Found by using the Monk product through the MCP tool surface (not by reading source).
• Reproducible with tools only (podman used solely as independent ground truth).
• Cross-verified across independent sources.
• Not a duplicate (dedup vs [Bug bounty] monk.workload.status misreports stopped workloads: ready/alive stay true, and stopped workloads vanish from status #234 below — different tool, different defect).

Stage: deployment / running-workload observability.
Coding agent: Claude Code (Opus 4.8), Monk plugin monk-agent v0.1.54.
Tool: monk.workload.logs (contradiction cross-checked against monk.workload.status).

---

Summary

After a workload is stopped, monk.workload.logs returns ok: true with log lines and no
field of any kind indicating the workload/container is stopped or exited. An operator or agent
calling workload.logs to check a service receives a healthy-looking response and cannot tell the
service is actually down.

This directly contradicts monk.workload.status, which for the same stopped workload returns
{ "workloads": [] } (the workload is absent entirely). So the two tool surfaces give mutually
inconsistent pictures of the same workload: status says it does not exist, logs says ok: true
and serves its logs. Ground truth (podman) is Exited (137).

Secondary defect: workload.logs's own error path is misleading. For a wrong/nonexistent container
name it returns "could not find any running containers" — implying it requires a running
container — yet it happily serves logs for a non-running (exited) container. The "running
containers" precondition is both falsely stated and inconsistently enforced.

---

Reproduction (tools only; podman = independent ground truth)

1. Running workload monk-test-app/app. monk.workload.status → state: "running", ready: true.
2. Stop it: monk.workload.stop { workload: "monk-test-app/app" } (approved).
3. monk.workload.status { } (fresh):

   { "workloads": [] }

   → the workload is gone from status.
4. monk.workload.logs { workload: "monk-test-app/app", tail: 5 }:

   {
     "ok": true,
     "workload": "monk-test-app/app",
     "tail": 5, "followMs": 0, "maxBytes": 262144,
     "truncated": false, "bytes": 55, "lineCount": 5,
     "logs": "probe-line\nprobe-line\nprobe-line\nprobe-line\nprobe-line\n"
   }

   → ok: true, log lines returned, no state/running/stopped/exited field. Nothing in
   the response reveals the workload is down.
5. Independent ground truth:

   podman ps -a → local-…-monk-test-app-app-main   Exited (137) … ago
   podman logs --tail 5 <container> → probe-line ×5   (identical to step 4)
   

   The container is genuinely stopped; workload.logs read its logs correctly but reported no
   stopped state.
6. Secondary defect — on the (previously running) workload, a bogus container name:

   monk.workload.logs { workload: "monk-test-app/app", container: "does-not-exist-xyz" }
   → MCP error: "…could not find any running containers"
   

   The message asserts a "running containers" requirement that step 4 shows is not actually the
   tool's behavior (it serves logs for a stopped container).

---

Cross-verification (3 independent sources)

1. monk.workload.logs → ok: true, lineCount: 5, no stopped indicator (step 4).
2. monk.workload.status → { "workloads": [] } for the same workload at the same time
   (step 3): the two MCP surfaces disagree on whether the workload even exists.
3. podman (ground truth) → container Exited (137); podman logs --tail 5 output byte-identical
   to workload.logs (step 5). Confirms the workload is stopped and that logs is live-reading the
   exited container while mislabeling its state.

---

Root cause

workload.logs resolves the container by name and streams its logs (podman serves logs for exited
containers) but never attaches the container run-state to its response, and does not reconcile
with the fact that workload.status no longer lists the workload. The result is a success-shaped
response for a down service. The "could not find any running containers" error string is a separate
inaccuracy in the same handler (it fires for absent/misnamed containers and misstates the
running-container precondition).

Note: this shares a root theme with #234 (stopped-workload state is not recomputed/surfaced) but is
a different tool and a different observable defect — #234 is about workload.status health
flags and the vanish; this is about workload.logs returning ok:true with no down-signal and
contradicting status.

It is also the opposite failure mode to #188. #188 (accepted, impact:high) is "workload.logs
cannot find a container that status reports as running" — logs fails on a running
workload (a false negative during container resolution). This report is the inverse: on a
stopped workload, logs succeeds (ok:true, serves logs) with no stopped indicator (a
false-positive / false-healthy signal). Opposite precondition (stopped vs running), opposite
direction (succeeds-when-it-should-signal-down vs fails-when-it-should-succeed), and a different
root cause (missing run-state in the response vs container-name resolution failing). Fixing #188's
resolution bug would not surface the stopped state this report is about.

---

Impact

• False health signal / observability: an agent-driven deploy or monitor loop naturally calls
  workload.logs to see what a service is doing; on a stopped service it gets ok: true + logs and
  no indication the service is down, so automation concludes the service is fine.
• Unreconcilable surfaces: status (workload absent) and logs (ok:true, serving logs) cannot
  both be right; there is no single source of truth for "is this workload running?" across the tool
  set.

Expected vs actual

• Expected: for a stopped workload, workload.logs either surfaces the container run-state
  (e.g. state: "stopped"/running: false) alongside the logs, or returns a clear
  stopped/not-running signal — and its error text names the actual condition (container not found)
  rather than "no running containers." The logs and status surfaces should agree on existence.
• Actual: workload.logs returns ok: true with logs and no state field for a stopped
  workload, while workload.status reports the same workload as absent; podman confirms Exited.

---

Environment

• OS: Windows 11 Pro (native monk-agent v0.1.54; runtime WSL Ubuntu-Monk, podman).
• Monk CLI/daemon: v3.21.1, build 0ecb47b4.
• Scope: personal / monk-test-app, local runnable monk-test-app/app.

Dedup check

gh search issues -R monk-io/monk-plugin "workload" surfaces two related-but-distinct issues:
#234 (workload.status ready/alive flags + vanish — different tool) and #188 (workload.logs
fails to find a container on a running workload — the opposite failure mode; see Root
cause for the point-by-point distinction). Neither covers a stopped workload where
workload.logs returns ok:true with no down-signal while workload.status reports the workload
absent.

Payout

N/A — reported for the Monk bug bounty; no payout expected for this report itself.

[jihadMo]

I have implemented the fix for monk.workload.logs response state transparency on stopped containers (#266). Added explicit running boolean and state string fields to the workload.logs response in scripts/workload-logs-state-fix.js, ensuring stopped/exited containers are transparently reported, alongside test coverage in tests/workload_logs_test.js.

Fix branch: https://github.com/jihadMo/capgo/tree/fix/workload-logs-surface-stopped-state