-
fix(cli): whoami respects the org selected via `orgs switch` (#3832)
发布于
2026-07-16 20:11:33 +00:00 Summary
composio whoamireports the wrong organization aftercomposio orgs switch.
It always shows the API key's home org, ignoring the switched-to org,
even
thoughcomposio orgs listcorrectly reflects the selection.Root cause:
whoamiresolves session info via
getSessionInfoByUserApiKey,
which sent onlyx-user-api-keyand omittedx-org-id. Without that
header the
backend falls back to the API key's home org. Consumer commands
(search,
execute, …) already forward the selected org via
resolveCommandProject, so
onlywhoamiwas affected — a display bug, not an API bug.Verification that the backend honors the header (direct calls to
GET /api/v3/auth/session/info):x-org-idreturned project/org org A org A org B org B (omitted) API key's home org Changes
getSessionInfoByUserApiKeyaccepts an optionalorgIdand forwards
it as
x-org-idwhen present (login-time callers pass none, so their behavior
is
unchanged).whoamipasses the selected global org (ctx.data.orgId).- Unit tests asserting the header is sent when an org is selected and
omitted
otherwise.
Type of change
- Bug fix
How Has This Been Tested?
- New unit tests:
test/src/services/composio-clients.test.ts(2
cases). - Existing
whoami.cmd.test.tsstill passes (5 tests total green). - Manual end-to-end with a real UAK against two orgs: a binary built
from this
branch reports the switched org correctly (orgs switch→whoami),
whereas the released 0.2.31 binary always reported the home org.
Checklist
- I have read the Code of Conduct and this PR adheres to it
- I ran linters/tests locally and they passed
- I updated documentation as needed (no user-facing docs affected)
- I added tests or explain why not applicable
- I added a changeset if this change affects published packages
下载附件