cli mode: API key project and CLI project can differ silently, and the gateway reports healthy

[leggetter]

Found while running the plugin against a real Hookdeck project for the first time.

What happens

In cli mode there are two independent notions of "which project":

• HOOKDECK_EG_API_KEY — what hermes hookdeck setup, status, replay, the dashboard tab and the agent tools act on.
• The Hookdeck CLI's own config (~/.config/hookdeck/config.toml) — what hookdeck listen forwards from.

Nothing reconciles them. When they differ:

1. hermes hookdeck setup <route> succeeds and reports a connection created — in the API key's project.
2. adapter.connect() returns True and logs mode=cli listening on 127.0.0.1:3579/hookdeck. The gateway considers itself healthy.
3. hookdeck listen runs against the CLI's project, does not find the source, auto-creates a stray source there, then exits with no connection found matching filter "<route>".
4. The supervisor restart-loops with capped backoff, so the failure repeats every 2s → 4s → 8s → … in the log and never escalates.
5. Every event published to the real source becomes a CLI_DISCONNECTED ignored event — events_count: 0, ignored_count: 1 on the request.

Observed log:

hookdeck.adapter: [hookdeck] mode=cli listening on 127.0.0.1:3579/hookdeck — ack_mode=async_retry ...
hookdeck.tunnel: [hookdeck cli] Source "hermes-livetest" not found.
hookdeck.tunnel: [hookdeck cli] Non-interactive mode detected. Automatically creating source "hermes-livetest".
hookdeck.tunnel: [hookdeck cli] no connection found matching filter "livetest" for source "hermes-livetest"
hookdeck.tunnel: [hookdeck] CLI tunnel exited after 1s — restarting in 2s

Everything above the tunnel lines reads like a working gateway.

Why it is worth fixing

The symptom is indistinguishable from "no events are arriving", which is the same symptom the CLI version floor exists to prevent — and doctor was written specifically so that class of problem is diagnosable. This one slips straight past it.

It also silently writes to a project the operator did not intend to touch (step 3).

Suggested fixes

1. doctor should compare the two. It already resolves the CLI binary and checks its version; reading project_id from the CLI config and comparing it against the project the API key belongs to is a small addition and would have turned ~20 minutes of confusion into one line of output.

2. The tunnel supervisor should escalate a deterministic failure. no connection found matching filter will never fix itself by retrying — unlike a network blip, which is what the backoff is for. Repeated identical early exits should be logged at error level with the likely cause named, rather than disappearing into an exponential backoff that reports nothing new.

3. Consider --hookdeck-config <path>. The CLI accepts a config path, so the adapter could point hookdeck listen at a gateway-owned config instead of depending on the operator's shared session. That would make the CLI's project a plugin setting rather than ambient state.

   Note: hookdeck ci --local is not a safe way to do this. Despite documenting "Save credentials to current directory", it also rewrote ~/.config/hookdeck/config.toml and switched the active project — confirmed on 2.4.0. That is a CLI bug and is being reported separately, but it is another reason not to have the gateway touch shared CLI state.

Workaround today

Make sure the CLI is logged into the same project as HOOKDECK_EG_API_KEY before starting the gateway. Documented in Limitations as of f11da5f.