Correct X-Kernel-Project-Id: header takes a project ID, not a name

[IlyaasK]

What

docs#409 described the X-Kernel-Project-Id header as accepting "a project ID or name." It does not — the middleware resolves it by project ID only (entproject.IDEQ), so a name returns 404 project_not_found. Verified live against a running API: the project name testingapikeygen 404'd, its ID resolved.

Fix

Clarify that the header takes a project ID; name resolution is a client-side convenience (the CLI's --project flag and the SDKs resolve names to IDs before sending the header). The CLI section of this page already documents --project <id-or-name> correctly and is unchanged.

🤖 Generated with Claude Code

---

Note

Low Risk
Documentation-only correction with no runtime or API behavior changes.

Overview
Fixes misleading docs in Scoping Requests to a Project (info/projects.mdx): X-Kernel-Project-Id is documented as accepting only a project ID, not a name (names in the header lead to 404 project_not_found).

The section now explains that CLI --project and SDK project settings resolve names to IDs before sending the header, while direct REST callers must set the header to the ID themselves. Default-project behavior when the header is omitted is unchanged.

^{Reviewed by Cursor Bugbot for commit ee5ece8. Bugbot is set up for automated code reviews on this repo. Configure here.}

[firetiger-agent]

Created a monitoring plan for this PR.

What this PR does: Fixes a documentation inaccuracy — the X-Kernel-Project-Id header only accepts a project ID, not a project name. Developers who previously passed a name would have received a 404 project_not_found error with no clear explanation in the docs.

Intended effect:

• No production telemetry signal exists for a docs-only change. Confirmation is manual: the published info/projects page should render correctly and show the corrected header description after merge.

Risks:

• Broken page render — MDX parse error causes the docs page to 404; alert if info/projects returns a non-200 after publish.
• Inaccurate correction — if the fix misstates the actual API behavior, developers using a project name would still receive 404 project_not_found; alert if project_not_found errors rise unexpectedly in API logs post-merge (baseline: pre-existing low-level noise, no sustained increase expected).

View monitor

[cursor]

Risk assessment: Very Low.

This PR changes one sentence in info/projects.mdx to clarify that X-Kernel-Project-Id accepts a project ID, while CLI/SDK name resolution happens before sending the header. The diff is documentation-only, limited to a single page, and doesn't change navigation, configuration, generated API specs, runtime code, infrastructure, auth, or security-sensitive behavior.

I didn't find a CODEOWNERS file requiring owner review, and there were no existing approvals, so I'm approving.

  

_{Sent by Cursor Automation: Assign PR reviewers}

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
Kernel	🟢 Ready	View Preview	Jun 22, 2026, 2:29 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[cursor]

Risk assessment: Very Low.

The current diff modifies a single sentence in info/projects.mdx to clarify project scoping guidance: CLI/SDK usage can be name-based while direct REST calls send X-Kernel-Project-Id as a project ID. This is documentation-only, limited to one page, and doesn't change navigation, configuration, generated API specs, runtime code, infrastructure, auth, or security-sensitive behavior.

I didn't find a CODEOWNERS file requiring owner review. This PR was already approved by this automation on an earlier commit, and the synchronized update doesn't increase risk, so I'm not re-approving or dismissing the existing approval.

  

_{Sent by Cursor Automation: Assign PR reviewers}