revert(cli): revert headless agent session control (#5784)

AGENTS.md

@@ -48,13 +48,6 @@ When a user asks for UI verification through the Chrome DevTools Protocol (CDP):
 5. **Treat a mismatch as an incomplete reproduction** - if the test passes but the user still observes the bug, re-check the target instance, exact steps, input method, persisted keys, and lifecycle timing. Reproduce the failure before changing code; do not assume the report is disproven by a synthetic smoke test.
 6. **Use an evidence gate** - for a reported bug or regression, do not claim it is verified until the original interaction demonstrably fails before the fix and passes after it under the same observations. For a new feature, record equivalent baseline evidence and demonstrate the expected behavior. In all cases, state clearly which checks were end-to-end, which were synthetic, and whether screenshots were actually captured.
 
-## CLI End-to-End Verification
-
-Run cross-process agent-session coverage with `bun run test:cli-e2e`; it uses an
-isolated home and a production-ABI PTY daemon. When the acceptance criterion
-includes the real desktop UI, follow `apps/desktop/docs/CLI_CDP_E2E.md` and
-preserve CLI output separately from genuine CDP screenshot evidence.
-
 ## Agent Rules
 1. **Type safety** - avoid `any` unless necessary
 2. **Prefer `gh` CLI** - when performing git operations (PRs, issues, checkout, etc.), prefer the GitHub CLI (`gh`) over raw `git` commands where possible

apps/desktop/AGENTS.md

@@ -49,11 +49,6 @@ export const createMyRouter = () => {
 
 To check a change end-to-end against the real API/DB, drive the running dev app over CDP. Launch with an unused port, for example `RENDERER_REMOTE_DEBUG_PORT=9222 bun dev` (full stack; the app may restore a signed-in session), then attach via the page target's `webSocketDebuggerUrl` over a WebSocket (Bun built-in, no deps). Example: `scripts/cdp-smoke-integrations.ts`.
 
-For a CLI-initiated journey, follow `docs/CLI_CDP_E2E.md`. It documents how to
-run the development CLI against this exact Electron instance's home directory
-and host manifest, then tie CLI-returned workspace/session IDs to real CDP input
-and `Page.captureScreenshot` evidence.
-
 **Never assume port 9222 or attach to a renderer from another worktree.** Multiple Superset workspaces commonly run at once, each with different renderer, API, and CDP ports. Before testing:
 
 1. Read this workspace's final `DESKTOP_VITE_PORT` and `NEXT_PUBLIC_API_URL` values from the root `.env`.
@@ -70,18 +65,14 @@ Check which setup script provisioned the workspace before repairing auth:
 - `.superset/setup.local.sh` creates a per-workspace local stack and runs the idempotent `bun run db:seed-dev`, but intentionally leaves sign-in as a separate step. If the account may be missing, rerun `bun run db:seed-dev` while the local DB stack is running.
 - `.superset/setup.sh` seeds `superset-dev-data/auth-token.enc` from `$HOME/.superset/auth-token.enc` when available. Rerunning it without `--force` can fill a missing token. Do not use `--force` merely to repair auth: it resets `superset-dev-data/` before reseeding.
 
-The desktop hydrates a persisted token into an in-memory bearer-token closure. A raw `Runtime.evaluate` sign-in `fetch` can create a cookie session, but it does not populate or persist the bearer token used by the Electron host-service coordinator. For a real Electron E2E journey, prefer the app-owned local-dev sign-in flow: navigate the matched renderer to `#/sign-in` and click **Sign in as Local Admin (dev)** through CDP `Input.dispatchMouseEvent`. That flow signs in, calls `electronTrpc.auth.persistToken`, updates the in-memory auth client, and navigates to the workspace UI. Do not replace this click with a raw sign-in request when the test needs host-backed features such as projects, workspaces, terminals, or agents.
-
-After the app-owned sign-in, verify `/api/auth/get-session` from the matched renderer with `credentials: "include"` and require both `session` and `session.activeOrganizationId`. If diagnosing bearer hydration, import `/lib/auth-client.ts` and return only a boolean such as `Boolean(getAuthToken())`; never return or print the token itself.
-
-If a test only needs a cookie-authenticated API probe and does not need the Electron host service, a workspace created by `setup.local.sh` can repair its CDP cookie session as follows:
+The desktop hydrates a persisted token into an in-memory bearer-token closure. A raw `Runtime.evaluate` `fetch` cannot read that closure, and the local-dev sign-in button persists a bearer token but uses `credentials: "omit"`; neither guarantees the cookie required by a raw CDP probe. For a workspace created by `setup.local.sh`, repair the CDP session as follows:
 
 1. Require a localhost API origin; never send dev credentials to a remote or shared API.
 2. From `apps/desktop` (so workspace imports resolve), import `DEV_EMAIL` and `DEV_PASSWORD` from `@superset/shared/dev-credentials`; do not copy their literal values into scripts or logs.
 3. Through `Runtime.evaluate` in the matched renderer, POST them to `${NEXT_PUBLIC_API_URL}/api/auth/sign-in/email` with JSON content type and `credentials: "include"`. Do not print the returned token or response body.
 4. Re-fetch `/api/auth/get-session` with `credentials: "include"` and require both `session` and `session.activeOrganizationId` before running the test.
 
-This credentialed local-dev sign-in creates the browser session cookie needed by subsequent in-renderer fetches, but it is not a substitute for the app-owned sign-in when host-backed behavior is under test. If it fails, report the sign-in/session status codes only. For a non-local setup, use the app's normal sign-in flow; never substitute local dev credentials.
+This credentialed local-dev sign-in creates the browser session cookie needed by subsequent in-renderer fetches. If it fails, report the sign-in/session status codes only. For a non-local setup, use the app's normal sign-in flow; never substitute local dev credentials.
 
 For a non-local workspace, the normal desktop flow intentionally restores an encrypted bearer token into the renderer's in-memory auth client without creating a browser cookie. If the renderer is on an authenticated route but a raw cookie-only probe returns no session, use `Runtime.evaluate` to import `/lib/auth-client.ts` from the renderer dev server and call `authClient.getSession({ fetchOptions: { throw: false } })`. This still verifies `/api/auth/get-session` through the app's real authenticated request path. Return only the status and `session.activeOrganizationId`; never call or print `getAuthToken()`.