`whoami` reports the previous project/org after `project use` (ignores active project_id)

[leggetter]

Summary

After switching projects with hookdeck project use, hookdeck whoami still reports the previously active project and organization, even though every other command (listen, connection list, etc.) correctly targets the newly selected project. This makes whoami misleading and undermines its main purpose — confirming which project you're operating on.

Observed on CLI v2.3.1.

Steps to reproduce

Given a user who belongs to projects in more than one org (e.g. Org A / Project and Org B / Project), currently active on Org A / Project:

$ hookdeck project use "Org B" "Project"
Successfully set active project to: Org B / Project
Saved to: ~/.config/hookdeck/config.toml

$ hookdeck whoami
Logged in as ... on project Project in organization Org A     # ← still Org A

Meanwhile the switch did take effect for everything else:

$ hookdeck connection list      # returns Org B / Project's connections
$ hookdeck listen 3030 my-src   # dashboard link is team_id=<Org B project id>

The config file confirms the active project changed:

project_id = '<Org B project id>'   # updated by `project use`

So the state is correct — only whoami's output is wrong.

Root cause

whoami resolves its display via ValidateAPIKey(), which calls clientForCLIAuthValidate() — a client copy that deliberately clears ProjectID so X-Team-ID / X-Project-ID are not sent:

https://github.com/hookdeck/hookdeck-cli/blob/main/pkg/hookdeck/auth.go#L136-L153

// clientForCLIAuthValidate returns a shallow copy of the client that omits
// X-Team-ID / X-Project-ID on requests. Stale project_id in config must not
// be sent to /cli-auth/validate — the server may prefer headers over the key's
// bound team and reject a valid key with 401.
func (c *Client) clientForCLIAuthValidate() *Client {
	return &Client{
		...
		ProjectID: "",
		...
	}
}

Because the project header is omitted, GET /cli-auth/validate resolves the project/org from the API key's bound team alone, ignoring the config's active project_id. hookdeck project use updates project_id in config but keeps the same user-associated API key (see UseProject in pkg/cmd/project_use.go), so whoami reports whatever project the key is bound to — the original one — regardless of the current selection.

The header is cleared intentionally to avoid a stale project_id triggering a 401 (per the comment), so simply sending the header again is not the right fix — it would risk reintroducing that failure.

whoami prints these fields at pkg/cmd/whoami.go#L45-L51.

Suggested direction

whoami should report the config's active project (project_id), not the key's bound team. Options:

1. After validating the key, resolve the active project_id to its name/org via the project list (/teams, already used by project use) and display that.
2. Or have whoami display the config's project_id and look up its display name, keeping the key-only validate call purely for auth.

Either way the goal is that whoami and project use agree on the active project.

Impact

This surfaced while debugging a "CLI won't receive events" support report. whoami is the natural command to confirm you're on the right project, and here it actively points at the wrong one. For users who share a project name across orgs (e.g. multiple Default Projects), the mismatch is easy to miss and can send someone debugging the wrong project.

Related

• Improve UX when stored credentials fail validation (login, whoami, MCP) #283 (Improve UX when stored credentials fail validation) — same validate path, different concern.