[Bug bounty] capsule.schedule.update: invalid schedule inputs are not validated and the approval dialog hides silently-dropped values

[mobster31]

Eligibility

• Found by using the Monk product through the MCP tool surface (not by reading source).
• Reproducible with tools only.
• Cross-verified across independent sources.
• Not a duplicate of an existing issue (dedup check below).

Stage: deployment / capsule scheduling configuration.
Coding agent: Claude Code (Opus 4.8), Monk plugin monk-agent v0.1.54.
Tool: monk.capsule.schedule.update (+ monk.capsule.schedule.get).

---

Summary

monk.capsule.schedule.update performs no validation of rule inputs before rendering the
security-approval prompt, and the prompt shown to the user is a sanitized view that no longer
matches what was submitted:

1. An invalid weekday (funday) is silently dropped. The approval dialog shows only the
   surviving day ([mon]) — the approver has no way to see that part of their submitted rule was
   discarded. A typo therefore silently narrows a schedule rule, and the security-approval dialog
   misrepresents the request being approved.
2. An impossible time (25:99) and a nonexistent IANA timezone (Mars/Phobos) are passed
   into the approval prompt verbatim, unvalidated.
3. After the user approves the change, monk.capsule.schedule.get still returns
   Not configured — the approved change does not persist and no error is surfaced to either
   the user (the approval simply vanishes) or the caller (the MCP call returned The operation timed out.).

So the tool both (a) accepts structurally-invalid schedule data without rejecting it, and (b)
misrepresents that data in the very dialog meant to let a human authorize the change.

---

Reproduction (tools only)

Bound workspace: monk.scope.status → personal / project monk-test-app (no capsules required;
project-scope schedule works with zero capsules).

1. Confirm no schedule exists:

   monk.capsule.schedule.get { scope: "project" }
   → { schedule: null, summary: ["Not configured."] }
   

2. Submit a schedule containing invalid values:

   monk.capsule.schedule.update {
     scope: "project",
     enabled: true,
     defaultState: "down",
     timezone: "Mars/Phobos",
     rules: [{ type: "weekly_window", days: ["funday","mon"],
               start: "25:99", end: "08:00", state: "up" }]
   }
   

3. Observe the approval prompt the tool generates (rendered plan):

   Proposed:
     Enabled: true
     Timezone: Mars/Phobos
     1. up weekly [mon] 25:99-08:00
   

   → funday is gone (silently dropped to [mon]); 25:99 and Mars/Phobos are kept verbatim.
   No validation error is returned; instead a destructive-config approval is queued.
4. Approve the change in the dashboard.
5. Read the result back:

   monk.capsule.schedule.get { scope: "project" }
   → { schedule: null, summary: ["Not configured."] }
   

   → The approved change did not persist, and no error was surfaced anywhere.

---

Cross-verification (3 independent sources)

1. MCP tool output — the schedule.update rendered plan (approval preview) shows
   weekly [mon] 25:99-08:00 and Timezone: Mars/Phobos: proof that funday was dropped while the
   impossible time and fake timezone survived unvalidated.
2. On-disk approval record — ~/.monk/agent/store/global/requests/approvals.json, entry
   aae62ed2 (monk.capsule.schedule.update), independently persists the same sanitized body and
   records status: approved, createdAt 2026-08-05T21:09:23.005Z, resolvedAt 2026-08-05T21:10:25.597Z. A prior identical attempt (0c67d192) shows the same drop.
3. Post-approval platform read — monk.capsule.schedule.get { scope: "project" } returns
   Not configured after the approval resolved, confirming the approved change was never applied
   and no validation/apply error was surfaced.

---

Root cause

Two distinct defects on the same tool:

• No input validation before prompting. days entries are filtered against the valid weekday
  set and invalid ones are dropped silently (rather than rejecting the call or warning), while
  timezone and start/end time strings are not validated at all before being placed into a
  human security-approval prompt. The approval dialog renders the post-filter value, so it no
  longer reflects the caller's actual submission.
• Approval outlives the MCP call (shared root cause with [Bug bounty] secret.remove approval outlives its MCP call — destructive deletion executes minutes after the caller is told it timed out #260). The originating MCP call timed
  out (~60s transport limit) ~2s before the user approved (resolvedAt 21:10:25.597 vs a call
  created 21:09:23.005). The late approval applied to nothing — the config was neither stored nor
  reported as failed. This is the same timeout-vs-approval-lifecycle root cause as [Bug bounty] secret.remove approval outlives its MCP call — destructive deletion executes minutes after the caller is told it timed out #260 (which
  jihadMo is fixing by linking approval cancellation to the MCP call timeout); that fix should be
  verified to cover capsule.schedule.update as well, and additionally the invalid input should be
  rejected up front.

---

Impact

• Approval integrity (security): a security-approval dialog must show exactly what is being
  authorized. Here it shows [mon] after silently discarding funday — the human approver cannot
  detect that their submitted request was altered before approval.
• Correctness / availability: a mistyped weekday silently changes which days a capsule is
  scheduled up/down; an impossible time (25:99) and nonexistent timezone (Mars/Phobos) are
  accepted into the plan with undefined downstream scheduling behavior.
• Broken lifecycle: an approved configuration change is silently a no-op — the user believes
  they configured a schedule, but nothing was stored and no error was raised.

Expected vs actual

• Expected: invalid days/timezone/time values are rejected with a clear error before any
  approval prompt; the approval dialog shows exactly the submitted rule; an approved change either
  persists or surfaces an explicit failure.
• Actual: invalid weekday silently dropped, impossible time and fake timezone accepted verbatim
  into the approval prompt, and the approved change neither persists nor reports an error.

---

Environment

• OS: Windows 11 Pro (native monk-agent v0.1.54; runtime in WSL Ubuntu-Monk).
• Monk CLI/daemon: v3.21.1, build: 0ecb47b4.
• Scope: personal / monk-test-app, project-scope capsule schedule, zero capsules.

Dedup check

gh search issues -R monk-io/monk-plugin "schedule" → only #96 (audit-log growth, unrelated).
gh search issues -R monk-io/monk-plugin "capsule" → #252 (capsule.setup GitHub-secret write,
different tool/bug). No existing issue covers capsule.schedule.update validation or the
schedule approval lifecycle. Related-but-distinct: #260 (secret.remove approval lifecycle) shares
the timeout root cause but is a different tool and a different (data-loss vs no-op + validation)
manifestation.

Payout

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

[jihadMo]

I have implemented the fix for monk.capsule.schedule.update input validation (#262). Added pre-flight validation of weekdays (mon-sun), start/end 24h HH:MM time strings, and IANA timezone format before rendering the security-approval prompt in scripts/schedule-update-validation.js, along with test coverage in tests/schedule_validation_test.js.

Fix branch: https://github.com/jihadMo/capgo/tree/fix/schedule-update-input-validation