Impersonation is invisible in the console — no indicator, no way out, and the shell keeps showing the ADMIN's identity while the session is the impersonated user

[baozhoutao]

Symptom

After an admin starts impersonation through the real product affordance, the console shows no sign of it anywhere and keeps rendering the admin's identity, while the session on the server is the impersonated user.

Server-side impersonation is correct — this is console-only. POST /api/v1/auth/admin/impersonate-user returns 200, GET /auth/get-session reports the impersonated user with session.impersonatedBy = <admin id>, the sys_session row records {user: <target>, by: <admin>}, and stop-impersonating works over the cookie lane.

What the console does with that:

• Full page reload of the Users page, /_console/home and the Setup app each re-rendered fresh: page text matched /impersonat/i → false, and /stop impersonat|exit impersonat|return to/i → false. There is no indicator and no way to stop.
• /_console/home greets "Good afternoon, Dev Admin." with the DA avatar — while that same page's own fetch('/api/v1/auth/get-session') returns user.email = rt8-dave@example.com, role: user, isPlatformAdmin: false.
• The platform-admin Setup navigation still renders for that non-admin session.

Reproduced twice with two independent drivers (row-action + reload; in-page fetch + three fresh navigations).

Why this matters beyond cosmetics

Every write made during impersonation is attributed to the impersonated user — that is the point of the feature. An admin who cannot tell they are impersonating will do ordinary work believing they are acting as themselves, and the audit trail will say someone else did it. There is also no affordance to get out, so the only exits are clearing cookies or knowing the API call.

Reproduction

1. Sign in to /_console/ as admin@objectos.ai / admin123 (use localhost, not 127.0.0.1 — sign-in enforces a trusted-origin check).
2. Setup → Users → switch to the All Users view → row menu on any other user → Impersonate User → Continue. Network confirms 200 POST /api/v1/auth/admin/impersonate-user and a toast "Now impersonating user".
3. Navigate to /_console/home (a fresh SPA boot, not a client-side route change).

Expected a visible impersonation indicator naming the impersonated user, plus a stop/exit affordance; and the shell showing the impersonated identity.
Actual the admin's name and avatar, admin navigation, no indicator, no exit — over a session that get-session reports as a non-admin user.

Note on scope

session.impersonatedBy is already on the wire, so the shell has everything it needs to render both the banner and the correct identity; this looks like the client identity state simply never being refreshed after the impersonation call, rather than missing server data.

Source

Found by the platform checklist retest of identity-auth.admin-lifecycle-operations clause 7 (framework 279ee48a, console pin 6314e87f2d49).

[yinlianghui]

CLAIM — session session_017Qqyix2QcnpUC9XeYVDzx3, branch claude/issue-4467-impersonation-visible.

Ruling (delegated authority; open veto window): the audit-integrity framing is the priority — an admin doing ordinary work under someone else's identity, invisibly, corrupts attribution. The card's scope note is the fix's shape: session.impersonatedBy is already on the wire; the client identity state simply never refreshes and nothing renders it.

1. Identity refreshes after impersonation state changes: after the impersonate call succeeds (and after stop-impersonating), the client session/identity state must re-resolve — measure how the console holds identity today (the auth client/session hook in packages/auth + whatever app-shell context consumes it) and invalidate/refetch at both transitions. The shell then shows the IMPERSONATED user's name/avatar (that is what the session IS), and admin-only navigation follows the real session's privileges — the card measured Setup nav still rendering for a non-admin session; that must stop.
2. A persistent impersonation banner whenever session.impersonatedBy is present: names the impersonated user AND the impersonating admin, carries a stop/exit affordance calling stop-impersonating then refreshing identity. It must survive full SPA reboots (it derives from the session, not from client memory of the click). Placement: the shell chrome level where it is visible on every console page — measure where global banners/announcements already mount, follow that convention; if none exists, the header region is the home.
3. i18n per the live convention (all-ten-packs parity, inline defaults).

Red-first: mocked session carrying impersonatedBy → pre-fix no /impersonat/i text anywhere and the shell shows the pre-impersonation identity (the card's own probes — capture); post-fix banner present naming both parties, stop affordance wired, identity = session user, admin nav absent for a non-admin session. Must-not-change (green both sides): a normal session (no impersonatedBy) renders zero banner and identical chrome; stop-impersonating restores the admin identity and the banner disappears.

Scope guard: console-only — the server side is measured correct; do not touch data-objectstack or server-adjacent code beyond reading the session shape. If the identity-state home turns out to be shared with the Users page's impersonate action in a way that demands refactoring beyond state invalidation, report the measurement first.

Grading: patch @object-ui/app-shell (+ @object-ui/auth patch ONLY if the session hook needs a refresh method exposed — .d.ts measured; additive export → minor per precedent, say so). Never major.

Surface (mutual exclusion): shell chrome/header + the impersonate action's call site (Setup Users page) + the session/identity state hook + tests + changesets. ⛔ NOT: console/organizations/manage/** (in-flight #4475), plugin packages (#4464/#4465), the test-support extraction (#4434), content/docs/releases/.

---

Generated by Claude Code

---

Generated by Claude Code

[yinlianghui]

RULING UPDATE (delegated authority; open veto window) — the dispatched dev STOPPED correctly and the measurement falsifies my original ruling's premise. New ruling: option A, visibility work in the same PR.

What the measurement established (full detail in the dev's report): identity state is NOT stale — it re-resolves every SPA boot, to the ADMIN, because (1) the console authenticates every /api/ request with the localStorage bearer; (2) better-auth's bearer plugin server-side OVERWRITES the request's session cookie with that bearer, so the impersonation cookie never wins; (3) the impersonate action runs over the DATA lane, which — unlike the auth lane (createAuthClient.ts:179, the repo's ONLY reader) — never adopts the rotated set-auth-token the server hands back. The impersonated session token is dropped on the floor. Impersonation is therefore a complete no-op in the console, and the audit risk is the INVERSE of the card's framing: support staff believe they see a user's view while acting entirely as themselves.

Why A (on the delegated axes): the business pull is measured, not speculative — a shipped, metadata-declared support feature is inert. The defect is an ASYMMETRY between two lanes injecting the same credential, where one honors the server's declared rotation contract and one discards it — fixing it is one-contract-one-answer, not a new transport decision (that would be option B, rejected; C fossilizes the bug behind phantom-green pins; D alone is an upstream card this seat cannot land). A also makes the banner derive from the session the console actually authenticates with, so the indicator structurally cannot disagree with who the server thinks is acting.

The A-scope (one PR): (1) createAuthenticatedFetch mirrors the auth lane's 3-line set-auth-token capture — lane symmetry, no impersonation-specific logic in a generic lane; (2) AuthProvider exposes a refresh, invoked after impersonate/stop; (3) impersonatedBy? widens AuthClientSession (patch per the #4495 precedent — interface widening, not a new export); (4) the banner/exit/i18n exactly as originally ruled, now reachable; (5) the exit affordance fails loudly when stop-impersonating cannot restore (the server resolves the admin via the admin_session COOKIE — in cookie-blocked deployments the exit cannot work; it must say so, never appear to succeed). Honest costs, recorded: the admin's token is replaced in localStorage for the duration; a client that misses the stop rotation is stranded until re-login. Accepted as the price of the feature actually functioning; D (server refuses bearer-shadowed impersonation) is being filed in objectstack as defence-in-depth.

Red-first correction (the dev's warning is adopted): the mocked-impersonatedBy harness of my original ruling would be a phantom pin — a state production cannot reach. The primary pin is LANE-LEVEL: a data-lane response carrying set-auth-token rotates TokenStorage (currently RED — the header is ignored) beside the auth lane's existing green. Banner/exit pins ride on the session the refreshed identity actually returns; what the jsdom harness cannot drive (the live server round trip) is stated in-file, not faked.

#4304 is being closed as a duplicate of this card (one extra datum recorded there: its build saw no Impersonate entry point).

---

Generated by Claude Code

---

Generated by Claude Code