fix: keep PostHog identity stable for Cloud context

[malhotra5]

HUMAN:

• A human has tested these changes.

AGENT:

This PR was created by an AI agent (OpenHands) on behalf of the user.

Verification performed:

• npx vitest run __tests__/services/telemetry.test.ts __tests__/hooks/use-telemetry-identity.test.ts — passed, 42 tests.
• npm run typecheck — passed.
• npm run build — passed; production app build completed with existing Vite/chunk-size warnings.
• npx eslint src/services/telemetry.ts src/services/telemetry-context.ts src/hooks/use-telemetry-identity.ts — passed.
• npx prettier --check src/services/telemetry.ts src/services/telemetry-context.ts src/hooks/use-telemetry-identity.ts __tests__/services/telemetry.test.ts __tests__/hooks/use-telemetry-identity.test.ts — passed.
• npm test — attempted twice; the full suite exceeded local timeouts after 180s and 360s respectively, with no test failures observed before timeout (second run reached 466/509 test files and 3847 passing tests before timeout).

---

Why

Agent Canvas currently used the Cloud user ID as the PostHog identity. That could change the effective PostHog distinct ID when users switch between local and Cloud backends in the same browser session, making cross-backend journey analysis harder.

Summary

• Stop identifying PostHog as the Cloud user; keep the browser/install distinct ID stable.
• Attach Cloud account context as event properties via the telemetry boundary (cloud_user_id, cloud_user_email) and clear it for local/loading/no-user states.
• Reset legacy previously identified PostHog users once, while preserving Canvas consent state, and add regression coverage for the new behavior.

Issue Number

OSS-5734

How to Test

1. Run npm ci if dependencies are not installed.
2. Run npx vitest run __tests__/services/telemetry.test.ts __tests__/hooks/use-telemetry-identity.test.ts.
3. Run npm run typecheck.
4. Run npm run build.
5. Optional: inspect PostHog event payloads while switching between local and Cloud backends. The PostHog user ID should not change to the Cloud user ID; Cloud events should include cloud_user_id / cloud_user_email, while local events should carry those properties as null.

Video/Screenshots

N/A — telemetry behavior change with no visible UI.

Type

• Bug fix
• Feature
• Refactor
• Breaking change
• Docs / chore

Notes

cloud_user_email is included because existing telemetry already attaches user_email; the new property scopes the Cloud email context explicitly to Cloud backend events.

@malhotra5 can click here to continue refining the PR

---

🐳 Docker images for this PR

• GHCR package: https://github.com/OpenHands/agent-canvas/pkgs/container/agent-canvas

Component	Value
Image	ghcr.io/openhands/agent-canvas
Architectures	amd64, arm64
Agent Server	ghcr.io/openhands/agent-server:1.37.0-python
Automation	openhands-automation==1.2.0
Commit	d405315720efb37d06b80b49fea71674f9074b23

Pull (multi-arch manifest)

# Multi-arch manifest — Docker automatically pulls the correct architecture
docker pull ghcr.io/openhands/agent-canvas:sha-d405315

Run

docker run -it --rm \
  -p 8000:8000 \
  ghcr.io/openhands/agent-canvas:sha-d405315

All tags pushed for this build

ghcr.io/openhands/agent-canvas:sha-d405315-amd64
ghcr.io/openhands/agent-canvas:oss-5734-stable-posthog-cloud-context-amd64
ghcr.io/openhands/agent-canvas:pr-1892-amd64
ghcr.io/openhands/agent-canvas:sha-d405315-arm64
ghcr.io/openhands/agent-canvas:oss-5734-stable-posthog-cloud-context-arm64
ghcr.io/openhands/agent-canvas:pr-1892-arm64
ghcr.io/openhands/agent-canvas:sha-d405315
ghcr.io/openhands/agent-canvas:oss-5734-stable-posthog-cloud-context
ghcr.io/openhands/agent-canvas:pr-1892

About Multi-Architecture Support

• Each tag (e.g., sha-d405315) is a multi-arch manifest supporting both amd64 and arm64
• Docker automatically pulls the correct architecture for your platform
• Individual architecture tags (e.g., sha-d405315-amd64) are also available if needed

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
agent-canvas	Ready	Preview, Comment	Jul 23, 2026 2:01pm

[hieptl]

Thank you! 🙏

[VascoSch92]

Took a careful look since this touches the telemetry boundary. Two things I think are blockers.

person_profiles is still identified_only

src/services/telemetry.ts:308 still passes person_profiles: "identified_only", but after this PR nothing calls identify(), setPersonProperties(), group() or alias() anywhere in the repo. In posthog-js 1.372.6 _hasPersonProcessing() returns false in exactly that situation, and the result gets stamped on every event as $process_person_profile, with person property payloads dropped server side.

So I think we stop creating person profiles entirely, not just for Cloud. Anything counting unique users as persons, filtering on person properties, or using cohorts would go empty. Given the PR is about preserving journey continuity that seems unintended, so worth checking with whoever owns the dashboards first. Passing $set on events won't work around it either, since _requirePersonProcessing only fires from the capture path when the flag is already true.

The legacy reset rotates distinct_id and defeats the OAuth bootstrap

clearLegacyIdentifiedUser calls posthog.reset(false), which clears persistence and re-registers with a fresh uuidv7. $device_id survives, distinct_id does not.

The problem is the interaction with readBootstrapIds() in telemetry-provider.tsx, which pulls distinct_id off the URL hash after Cloud login precisely to keep identity stable across the redirect. We bootstrap that ID and then immediately call clearLegacyIdentifiedUser on line 319. For anyone identified before this deploy $user_id is still sitting in localStorage, so the reset fires and discards the ID we just bootstrapped.

First load after deploy, every existing Cloud user gets a new distinct_id, their historical canvas_install and funnel events stay stranded on the old one, and the OAuth handoff is defeated for exactly the population it exists for. Could we alias the old ID, or skip the cleanup when init was bootstrapped?

Two smaller ones

cloud_user_email can hold a git config email. use-telemetry-identity.ts:15 falls back to settings.git_user_email, which is a separate field from settings.email and is populated on local backends too, and the new test asserts exactly that. use-tracking.ts:72 already sends the same expression as user_email, so events now carry the value twice under two names. Probably want to scope this one to settings.email.

use-telemetry-identity.ts:23 nulls Cloud context while the identity query loads, where the old code preserved it deliberately. Resolving takes two sequential requests, and the backend isn't in targets until an org resolves, so early events on a fresh Cloud load go out with cloud_user_id: null. Was losing that window intentional? The new test locks the behavior in so I want to be sure it's a decision rather than a side effect.

Minor: clearLegacyIdentifiedUser runs on both 319 and 325, and the second call can never do anything since 319 already cleared persistence. Also AGENTS.md line 40 says legacy users are reset "once", but it actually runs on every capture via line 635.

[malhotra5]

Addressed the telemetry review feedback in 2fb71fd:\n\n- switched the Canvas PostHog client to person_profiles: \"always\" so anonymous stable distinct IDs still create person profiles without identifying as the Cloud user\n- made legacy identified-user cleanup run only on initial PostHog initialization without OAuth bootstrap IDs, so OAuth bootstrap distinct/session IDs are preserved\n- removed repeated legacy cleanup from capture/consent paths\n- scoped cloud_user_email to the Cloud account email only, not git config email\n- preserved existing Cloud context while the Cloud identity query is still loading\n- added isolated bootstrap regression coverage plus updated hook/service tests\n\nVerification run locally:\n- npx vitest run __tests__/services/telemetry-bootstrap.test.ts __tests__/services/telemetry.test.ts __tests__/hooks/use-telemetry-identity.test.ts __tests__/hooks/use-telemetry.test.tsx\n- npm run typecheck\n- npm run build\n- targeted ESLint/Prettier checks\n\nThis PR comment was created by an AI agent (OpenHands) on behalf of the user.

[malhotra5]

Follow-up pushed in da8bdde:\n\n- cloud_user_email now falls back to git_user_email when settings.email is absent\n- removed automatic user_email from useTracking common properties so email is tracked only as cloud_user_email while Cloud context is active\n- updated the hook tests and telemetry architecture note\n\nLocal verification:\n- npx vitest run __tests__/hooks/use-telemetry-identity.test.ts __tests__/hooks/use-tracking.test.ts __tests__/services/telemetry.test.ts __tests__/services/telemetry-bootstrap.test.ts\n- npm run typecheck\n- targeted ESLint/Prettier checks\n\nThis PR comment was created by an AI agent (OpenHands) on behalf of the user.

[github-actions]

✅ Mock-LLM E2E Tests

60/60 passed

Commit: d4053157 · Workflow run · Test artifacts

Details

Status	Test	Duration
✅	automations/mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 1: setup LLM profile and register automation trajectory	7.1s
✅	automations/mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 2: create automation and dispatch run via the UI	27.5s
✅	automations/mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 3: verify automation and run on the automations page	6.1s
✅	automations/mock-llm-preset-automation.spec.ts › preset automation → slash command conversation › automation card sends the correct slash command to a conversation	15.3s
✅	automations/mock-llm-preset-automation.spec.ts › preset automation → slash command conversation › direct slash command from home page triggers skill activation	12.9s
✅	backends/mock-llm-auth-modes.spec.ts › auth mode: fresh install with runtime-injected key › reaches the onboarding modal without pre-seeded localStorage	1.5s
✅	backends/mock-llm-auth-modes.spec.ts › auth mode: non-public key rotation › recovers when localStorage has a stale session API key	5.4s
✅	backends/mock-llm-auth-modes.spec.ts › auth mode: public gate › shows first-run onboarding before the auth screen when no key is configured	1.5s
✅	backends/mock-llm-auth-modes.spec.ts › auth mode: public gate › rejects an incorrect key with an inline error	1.7s
✅	backends/mock-llm-auth-modes.spec.ts › auth mode: public gate › allows access after pasting the correct key	1.8s
✅	backends/mock-llm-auth-modes.spec.ts › auth mode: public gate › skips auth screen for returning user with valid stored key	851ms
✅	backends/mock-llm-auth-modes.spec.ts › auth mode: public gate › re-prompts when the server rotates its key (stale localStorage)	1.5s
✅	backends/mock-llm-cross-connect.spec.ts › cross-connect: frontend-only → backend-only › frontend-only connects to a separate backend-only instance	15.8s
✅	backends/mock-llm-cross-connect.spec.ts › cross-connect: frontend-only → multiple backends › connects to two separate backends and switches between them	19.9s
✅	backends/mock-llm-partial-stack.spec.ts › partial stack: --frontend-only › serves the frontend but returns 503 for backend routes	7.4s
✅	backends/mock-llm-partial-stack.spec.ts › partial stack: --backend-only › serves backend APIs but returns 503 for the frontend root	14.3s
✅	backends/mock-llm-partial-stack.spec.ts › partial stack: port conflict › fails with a clear error when the ingress port is occupied	97ms
✅	backends/mock-llm-partial-stack.spec.ts › partial stack: port conflict › starts successfully on a free port after a conflict	6.0s
✅	conversations/mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 1: create an LLM profile pointing at the mock LLM server	6.3s
✅	conversations/mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 2: activate the mock-llm profile and verify settings API	10.4s
✅	conversations/mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 3: run a conversation with the mock LLM	6.6s
✅	conversations/mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 4: resume conversation from sidebar after navigating away	5.8s
✅	conversations/mock-llm-image-upload.spec.ts › mock-LLM image upload › attaching an image embeds it as base64 in the LLM completion call	12.9s
✅	files/mock-llm-files-and-git.spec.ts › files tab, git control bar, and browser tab › step 1: ensure mock LLM profile is configured	6.6s
✅	files/mock-llm-files-and-git.spec.ts › files tab, git control bar, and browser tab › step 2: start conversation and attach workspace metadata	11.8s
✅	files/mock-llm-files-and-git.spec.ts › files tab, git control bar, and browser tab › step 3: git control bar shows workspace pill and git actions	25.3s
✅	files/mock-llm-files-and-git.spec.ts › files tab, git control bar, and browser tab › step 4: files tab can enable diff view for attached workspace	5.9s
✅	files/mock-llm-files-and-git.spec.ts › files tab, git control bar, and browser tab › step 5: browser tab shows empty state	6.4s
✅	files/mock-llm-files-and-git.spec.ts › files tab, git control bar, and browser tab › step 6: files tab defaults to file-tree view without attached workspace	7.5s
✅	home/mock-llm-folder-workspace.spec.ts › mock-LLM folder browser → workspace → conversation › step 1: browse to a folder, add it as a workspace, and launch a conversation with the correct working_dir	7.8s
✅	mcp/mock-llm-mcp-github.spec.ts › MCP GitHub server install flow › step 1: GitHub card is visible on the MCP marketplace page	5.6s
✅	mcp/mock-llm-mcp-github.spec.ts › MCP GitHub server install flow › step 2: clicking GitHub add control opens the install modal with correct fields	5.7s
✅	mcp/mock-llm-mcp-github.spec.ts › MCP GitHub server install flow › step 3: full install flow — fill PAT, submit, verify installed	12.3s
✅	mcp/mock-llm-mcp-github.spec.ts › MCP GitHub server install flow › step 4: installed GitHub server can be deleted	6.4s
✅	mcp/mock-llm-mcp-slack-credentials.spec.ts › MCP Test Connection credential verification (Slack) › install: invalid Slack credentials are blocked with a credential-check error	5.8s
✅	mcp/mock-llm-mcp-slack-credentials.spec.ts › MCP Test Connection credential verification (Slack) › install: a valid token missing only a scope still installs (missing_scope is not a credential failure)	6.0s
✅	mcp/mock-llm-mcp-slack-credentials.spec.ts › MCP Test Connection credential verification (Slack) › install: an older agent server that omits tool_result still installs (compat)	5.9s
✅	mcp/mock-llm-mcp-slack-credentials.spec.ts › MCP Test Connection credential verification (Slack) › edit: Test Connection verifies the stored credentials and surfaces a credential failure	5.7s
✅	mcp/mock-llm-mcp-slack-credentials.spec.ts › MCP Test Connection credential verification (Slack) › edit: Test Connection reports success for valid stored credentials	5.8s
✅	mcp/mock-llm-mcp-slack-credentials.spec.ts › MCP Test Connection credential verification (Slack) › custom (non-catalog) server: Test Connection attaches no verification probe	5.8s
✅	onboarding/mock-llm-onboarding-happy-path.spec.ts › onboarding happy path › completes the full onboarding flow and launches a conversation	4.5s
✅	onboarding/mock-llm-onboarding-regressions.spec.ts › onboarding recent regressions › keeps the modal open on backdrop click and Escape	1.5s
✅	onboarding/mock-llm-onboarding-regressions.spec.ts › onboarding recent regressions › defaults the LLM setup step to OpenAI GPT-5.5	1.6s
✅	regressions/mock-llm-ui-regressions.spec.ts › UI regressions › scopes standalone styles to the agent-server-ui shell	1.4s
✅	regressions/mock-llm-ui-regressions.spec.ts › UI regressions › renders critic results on agent messages and finish actions	1.5s
✅	regressions/mock-llm-ui-regressions.spec.ts › UI regressions › loads older events when scrolling up	1.8s
✅	regressions/mock-llm-ui-regressions.spec.ts › UI regressions › selected workspace persists after navigating away and returning	2.5s
✅	regressions/mock-llm-ui-regressions.spec.ts › UI regressions › cleared sessionStorage yields empty workspace selection	1.1s
✅	settings/mock-llm-acp-agent.spec.ts › mock-LLM ACP agent conversation › step 1: configure ACP agent via Settings → Agent UI	13.4s
✅	settings/mock-llm-acp-agent.spec.ts › mock-LLM ACP agent conversation › step 2: reload and verify ACP settings are persisted in UI	5.7s
✅	settings/mock-llm-acp-agent.spec.ts › mock-LLM ACP agent conversation › step 3: start ACP conversation and verify agent reply	6.2s
✅	settings/mock-llm-acp-agent.spec.ts › mock-LLM ACP agent conversation › step 4: resume ACP conversation from sidebar after navigating away	5.7s
✅	settings/mock-llm-model-switch.spec.ts › mock-LLM /model slash command › step 1: configure LLM, create switch-target profile, register trajectory	12.5s
✅	settings/mock-llm-model-switch.spec.ts › mock-LLM /model slash command › step 2: start conversation, switch profile via /model, verify switch	6.9s
✅	settings/mock-llm-profile-management.spec.ts › active profile deletion + reconciliation › active profile is deletable and reconciliation activates another profile	8.1s
✅	settings/mock-llm-profile-management.spec.ts › same-model profile identity › chat header shows the correct profile when two profiles share the same model	15.6s
✅	settings/mock-llm-profile-management.spec.ts › OpenHands provider hidden base_url preservation › re-saving an OpenHands profile from Basic view preserves hidden base_url	7.7s
✅	skills/mock-llm-skills.spec.ts › skill loading: project, user, and deletion › project skill in workspace/.agents/skills/ triggers on matching keyword	13.0s
✅	skills/mock-llm-skills.spec.ts › skill loading: project, user, and deletion › user skill in ~/.openhands/skills/ triggers on matching keyword	12.9s
✅	skills/mock-llm-skills.spec.ts › skill loading: project, user, and deletion › deleting a user skill removes it from subsequent conversations	12.8s

_{Posted by the Mock-LLM E2E workflow · results are deterministic (scripted LLM responses)}

[github-actions]

✅ Mock-LLM Docker E2E Test Results

60/60 passed

Commit: d4053157 · Workflow run · Test artifacts

Details

Status	Test	Duration
✅	automations/mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 1: setup LLM profile and register automation trajectory	6.6s
✅	automations/mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 2: create automation and dispatch run via the UI	33.5s
✅	automations/mock-llm-automation.spec.ts › mock-LLM automation lifecycle › step 3: verify automation and run on the automations page	6.3s
✅	automations/mock-llm-preset-automation.spec.ts › preset automation → slash command conversation › automation card sends the correct slash command to a conversation	15.6s
✅	automations/mock-llm-preset-automation.spec.ts › preset automation → slash command conversation › direct slash command from home page triggers skill activation	12.9s
✅	backends/mock-llm-auth-modes.spec.ts › auth mode: fresh install with runtime-injected key › reaches the onboarding modal without pre-seeded localStorage	1.6s
✅	backends/mock-llm-auth-modes.spec.ts › auth mode: non-public key rotation › recovers when localStorage has a stale session API key	5.4s
✅	backends/mock-llm-auth-modes.spec.ts › auth mode: public gate › shows first-run onboarding before the auth screen when no key is configured	1.5s
✅	backends/mock-llm-auth-modes.spec.ts › auth mode: public gate › rejects an incorrect key with an inline error	1.7s
✅	backends/mock-llm-auth-modes.spec.ts › auth mode: public gate › allows access after pasting the correct key	1.7s
✅	backends/mock-llm-auth-modes.spec.ts › auth mode: public gate › skips auth screen for returning user with valid stored key	858ms
✅	backends/mock-llm-auth-modes.spec.ts › auth mode: public gate › re-prompts when the server rotates its key (stale localStorage)	1.5s
✅	backends/mock-llm-cross-connect.spec.ts › cross-connect: frontend-only → backend-only › frontend-only connects to a separate backend-only instance	24.0s
✅	backends/mock-llm-cross-connect.spec.ts › cross-connect: frontend-only → multiple backends › connects to two separate backends and switches between them	20.8s
✅	backends/mock-llm-partial-stack.spec.ts › partial stack: --frontend-only › serves the frontend but returns 503 for backend routes	7.4s
✅	backends/mock-llm-partial-stack.spec.ts › partial stack: --backend-only › serves backend APIs but returns 503 for the frontend root	15.4s
✅	backends/mock-llm-partial-stack.spec.ts › partial stack: port conflict › fails with a clear error when the ingress port is occupied	107ms
✅	backends/mock-llm-partial-stack.spec.ts › partial stack: port conflict › starts successfully on a free port after a conflict	6.0s
✅	conversations/mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 1: create an LLM profile pointing at the mock LLM server	6.3s
✅	conversations/mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 2: activate the mock-llm profile and verify settings API	6.5s
✅	conversations/mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 3: run a conversation with the mock LLM	6.4s
✅	conversations/mock-llm-conversation.spec.ts › mock-LLM agent-server conversation › step 4: resume conversation from sidebar after navigating away	5.8s
✅	conversations/mock-llm-image-upload.spec.ts › mock-LLM image upload › attaching an image embeds it as base64 in the LLM completion call	12.6s
✅	files/mock-llm-files-and-git.spec.ts › files tab, git control bar, and browser tab › step 1: ensure mock LLM profile is configured	6.6s
✅	files/mock-llm-files-and-git.spec.ts › files tab, git control bar, and browser tab › step 2: start conversation and attach workspace metadata	11.4s
✅	files/mock-llm-files-and-git.spec.ts › files tab, git control bar, and browser tab › step 3: git control bar shows workspace pill and git actions	25.3s
✅	files/mock-llm-files-and-git.spec.ts › files tab, git control bar, and browser tab › step 4: files tab can enable diff view for attached workspace	5.9s
✅	files/mock-llm-files-and-git.spec.ts › files tab, git control bar, and browser tab › step 5: browser tab shows empty state	6.3s
✅	files/mock-llm-files-and-git.spec.ts › files tab, git control bar, and browser tab › step 6: files tab defaults to file-tree view without attached workspace	7.3s
✅	home/mock-llm-folder-workspace.spec.ts › mock-LLM folder browser → workspace → conversation › step 1: browse to a folder, add it as a workspace, and launch a conversation with the correct working_dir	7.3s
✅	mcp/mock-llm-mcp-github.spec.ts › MCP GitHub server install flow › step 1: GitHub card is visible on the MCP marketplace page	5.5s
✅	mcp/mock-llm-mcp-github.spec.ts › MCP GitHub server install flow › step 2: clicking GitHub add control opens the install modal with correct fields	6.3s
✅	mcp/mock-llm-mcp-github.spec.ts › MCP GitHub server install flow › step 3: full install flow — fill PAT, submit, verify installed	12.5s
✅	mcp/mock-llm-mcp-github.spec.ts › MCP GitHub server install flow › step 4: installed GitHub server can be deleted	5.9s
✅	mcp/mock-llm-mcp-slack-credentials.spec.ts › MCP Test Connection credential verification (Slack) › install: invalid Slack credentials are blocked with a credential-check error	5.8s
✅	mcp/mock-llm-mcp-slack-credentials.spec.ts › MCP Test Connection credential verification (Slack) › install: a valid token missing only a scope still installs (missing_scope is not a credential failure)	5.8s
✅	mcp/mock-llm-mcp-slack-credentials.spec.ts › MCP Test Connection credential verification (Slack) › install: an older agent server that omits tool_result still installs (compat)	6.0s
✅	mcp/mock-llm-mcp-slack-credentials.spec.ts › MCP Test Connection credential verification (Slack) › edit: Test Connection verifies the stored credentials and surfaces a credential failure	5.8s
✅	mcp/mock-llm-mcp-slack-credentials.spec.ts › MCP Test Connection credential verification (Slack) › edit: Test Connection reports success for valid stored credentials	5.8s
✅	mcp/mock-llm-mcp-slack-credentials.spec.ts › MCP Test Connection credential verification (Slack) › custom (non-catalog) server: Test Connection attaches no verification probe	5.8s
✅	onboarding/mock-llm-onboarding-happy-path.spec.ts › onboarding happy path › completes the full onboarding flow and launches a conversation	3.8s
✅	onboarding/mock-llm-onboarding-regressions.spec.ts › onboarding recent regressions › keeps the modal open on backdrop click and Escape	1.5s
✅	onboarding/mock-llm-onboarding-regressions.spec.ts › onboarding recent regressions › defaults the LLM setup step to OpenAI GPT-5.5	1.6s
✅	regressions/mock-llm-ui-regressions.spec.ts › UI regressions › scopes standalone styles to the agent-server-ui shell	1.0s
✅	regressions/mock-llm-ui-regressions.spec.ts › UI regressions › renders critic results on agent messages and finish actions	1.6s
✅	regressions/mock-llm-ui-regressions.spec.ts › UI regressions › loads older events when scrolling up	1.8s
✅	regressions/mock-llm-ui-regressions.spec.ts › UI regressions › selected workspace persists after navigating away and returning	2.1s
✅	regressions/mock-llm-ui-regressions.spec.ts › UI regressions › cleared sessionStorage yields empty workspace selection	1.1s
✅	settings/mock-llm-acp-agent.spec.ts › mock-LLM ACP agent conversation › step 1: configure ACP agent via Settings → Agent UI	13.3s
✅	settings/mock-llm-acp-agent.spec.ts › mock-LLM ACP agent conversation › step 2: reload and verify ACP settings are persisted in UI	5.8s
✅	settings/mock-llm-acp-agent.spec.ts › mock-LLM ACP agent conversation › step 3: start ACP conversation and verify agent reply	6.7s
✅	settings/mock-llm-acp-agent.spec.ts › mock-LLM ACP agent conversation › step 4: resume ACP conversation from sidebar after navigating away	5.7s
✅	settings/mock-llm-model-switch.spec.ts › mock-LLM /model slash command › step 1: configure LLM, create switch-target profile, register trajectory	12.7s
✅	settings/mock-llm-model-switch.spec.ts › mock-LLM /model slash command › step 2: start conversation, switch profile via /model, verify switch	6.7s
✅	settings/mock-llm-profile-management.spec.ts › active profile deletion + reconciliation › active profile is deletable and reconciliation activates another profile	8.4s
✅	settings/mock-llm-profile-management.spec.ts › same-model profile identity › chat header shows the correct profile when two profiles share the same model	14.8s
✅	settings/mock-llm-profile-management.spec.ts › OpenHands provider hidden base_url preservation › re-saving an OpenHands profile from Basic view preserves hidden base_url	7.9s
✅	skills/mock-llm-skills.spec.ts › skill loading: project, user, and deletion › project skill in workspace/.agents/skills/ triggers on matching keyword	12.9s
✅	skills/mock-llm-skills.spec.ts › skill loading: project, user, and deletion › user skill in ~/.openhands/skills/ triggers on matching keyword	12.7s
✅	skills/mock-llm-skills.spec.ts › skill loading: project, user, and deletion › deleting a user skill removes it from subsequent conversations	12.7s

_{Posted by the Mock-LLM E2E workflow · results are deterministic (scripted LLM responses)}