[Bug bounty] Registry ensure reports ready after daemon registry login RPC fails

[Onui2]

Bounty eligibility

• I have signed up at monk.io with this GitHub account
• I have used the product through the installed plugin and current Agent
• I have starred this repository

Stage

deploy / cluster registry

This exercises the cluster registry and deploy paths called out for deep-dive
testing in #156.

Coding agent

OpenAI Codex

Coding agent version

Codex CLI 0.145.0 in Codex desktop; Monk plugin and Agent 0.1.52

Repro steps

1. Install Monk plugin 0.1.52 and Agent 0.1.52.

2. Select a reachable cluster that already has valid registry-auth
   credentials under system/registry.

3. Arrange for the daemon registry-login RPC to reject the credentials:

   secrets.Get(registry-auth, system/registry) -> valid credentials
   auth.DockerLogin                           -> error:
                                                 registry login rejected
   

4. Call:

   {
     "name": "monk.cluster.registry.ensure",
     "arguments": {
       "workspaceRoot": "<workspace>"
     }
   }

5. Inspect the MCP response and matching durable action.

6. Immediately call monk.project.deploy against the same cluster while the
   same auth.DockerLogin rejection is active.

7. As a control, repeat monk.cluster.registry.ensure while allowing
   auth.DockerLogin to succeed.

I reproduced this with the real Agent MCP, action store, dashboard API, deploy
service, and bounded loopback cluster protocol fixture. All registry values
were fixed dummy values.

Expected behavior

monk.cluster.registry.ensure should succeed only after the daemon accepts the
registry login.

If auth.DockerLogin fails, the registry step and overall action should fail,
and the error should be returned to the caller. The tool must not claim that
the registry is ready or available.

Actual behavior

The fixture transcript records the affected login as a JSON-RPC error:

{
  "method": "auth.DockerLogin",
  "message": "fixture registry login rejected"
}

The affected MCP tool still returns:

{
  "ok": true,
  "actionId": "7b5e0cce-9f21-4a02-a81a-b12daf04feae",
  "message": "Cluster registry is ready.",
  "result": {
    "address": "fixture-registry.invalid:5000",
    "username": "fixture-user"
  }
}

The matching durable action also records full success:

{
  "status": "succeeded",
  "message": "Cluster registry is ready.",
  "registry": {
    "status": "succeeded",
    "message": "Registry is available at fixture-registry.invalid:5000."
  }
}

An immediate monk.project.deploy against the same cluster surfaces the same
login rejection and fails:

{
  "mcpError": "fixture registry login rejected",
  "actionStatus": "failed",
  "registryStepStatus": "failed",
  "registryStepMessage": "fixture registry login rejected"
}

When the third fixed auth.DockerLogin call succeeds, the control ensure call
also succeeds. This separates the ignored login failure from registry-secret
lookup, cluster selection, and action persistence.

Severity (my guess)

major

The tool whose purpose is to create or repair a deployment registry reports
that the registry is ready after its daemon login failed. Agents can continue
with deployment based on a false success, only to fail at the deploy registry
step with the error that ensure silently discarded.

This blocks the normal repair workflow: rerunning ensure gives another success
record instead of exposing the registry authentication problem that must be
fixed.

OS

Microsoft Windows 11 Pro 10.0.26100, build 26100

monkd version

No external monkd was used. Cluster RPC was replaced by a deterministic
loopback protocol fixture. Exact tested Agent: monk-agent 0.1.52.

Target cloud

None. No real cloud, registry, credential, image, workload, or Docker login was
used.

Integration

Monk cluster registry and deploy MCP:

• monk.cluster.registry.ensure
• monk.project.deploy

Verification notes

• Exact Agent SHA-256:
  9A2A3BE82B349B485BD73A4F6107741709311F41338A27B08168DA4EA995A76D
• Passing proof runs:
  • 20260731-110336-265
  • 20260731-110344-523
• Both independent runs passed all 14/14 assertions.
• Each run fixed exactly three registry reads and three login calls:
  affected ensure failure, downstream deploy failure, successful ensure
  control.
• No registry approval was created.
• Fresh isolated MONK_AGENT_HOME and random non-default ports were used.
• Browser launch was disabled and default Agent port 7419 was untouched.
• Proof SHA-256 values:
  • 5C480CBB098ED4FCCFFEF8E3A4D8B18C80BEE41F8FDB42B4C8CF66C745A42D3E
  • 838BE742EB947155F7943D279BAA74304C13D12AD528D1B5755DC8F1567B21EF

Root cause and suggested fix

The existing-registry branch catches and discards the login rejection:

await monk.registry.login({
  server: existing.address,
  username: existing.username,
  password: existing.password,
  alias: ["registry.local"],
  insecure: existing.tlsVerify === false,
}).catch(() => undefined);

await actions.completeStep(
  actionId,
  "registry",
  `Registry is available at ${existing.address}.`,
);
return existing;

Remove the empty catch and propagate the login failure. If the operation is
intentionally best-effort, return an explicit partial/error result and do not
complete the registry step or overall action as successful.

Add a regression test where valid stored credentials are returned but
registry.login rejects. Assert that the MCP result, registry step, and action
all fail. Keep a successful-login control.

The same ignored call shape also appears in registry creation and reset code,
but this report's dynamic proof and impact claim are limited to the existing
registry path above.

Duplicate check

Fresh public searches at 2026-07-31T02:04:12Z covered open and closed issues
through #201. Searches for auth.DockerLogin, Cluster registry is ready,
Registry is available login, registry.ensure, registry ensure deploy fails, registry login error swallowed, and cluster registry ready deploy
found no matching report.

Issue #201 is distinct: it covers a final workload-status verification error
after a deploy update. This report covers registry ensure discarding the
daemon registry-login failure before deployment.

OpenAI Codex assisted with the bounded product runs, reproduction, impact
control, evidence extraction, duplicate search, and report preparation, as
permitted by the contest.

[nooga]

This is exactly the kind of deep-feature testing we want more of — tagged deep and +2 points added to your score. See the pinned issue (#156) if you want more ideas in this space.