companion: remove the app-specific bridge and stabilize token capabilities

[RaresKeY]

Prerequisites

• I searched open issues, discussions, and the companion PR series for an existing removal and stabilization tracker with this scope.
• I checked the companion code and related open work against the current dev branch.
• This is a concrete, actionable proposal: stop expanding the app-specific bridge, stabilize the token boundary, and remove the bridge in focused slices.

Area

Auth / Security

Problem or Motivation

Current dev contains a server-side companion bridge and pairing flow introduced by #863, #871, and #877, with later fixes such as #4319. The broader proposal in #3244 explicitly asked whether an in-tree companion bridge and app were wanted, but I could not find a recorded maintainer decision establishing a specific third-party companion app as a core-supported product surface.

The open series continues to expand that surface across sessions, files, notes, tasks, email, calendar, push notifications, research, settings, terminal access, and administration. That creates three problems during stabilization:

• Core is acquiring an app-specific compatibility and support contract before maintainers have agreed on ownership, architecture, product scope, or long-term maintenance.
• Pairing and owner attribution broaden the authentication boundary. A credential presented as narrow integration access must not silently inherit unrelated capabilities merely because it belongs to an owner account.
• Splitting the feature across many individually plausible PRs makes the aggregate architecture and security cost difficult to review.

This is not an argument against mobile access. The responsive web UI, PWA behavior, SSH or VPN-based deployment, webhooks, and deliberately documented generic APIs should remain available. A native companion app can be reconsidered later if maintainers explicitly choose to own it, define its threat model and API contract, and decide whether it belongs in-tree. Until then, Odysseus should not promote or preserve an app-specific compatibility layer for an external client.

Proposed Solution

Use this issue as the parent tracker for an ordered rollback and stabilization pass against current dev.

Initial order:

Order	Slice	Purpose	Candidate
1	#5677 - Mounted-path auth normalization	Make middleware policy evaluate the same application-relative path as Starlette routing	Draft PR #5678
2	#5676 - Cookbook bearer boundary	Retire the inconsistent Cookbook token scopes and keep model deployment, host control, task logs, saved commands, and credentials inside the trusted operator-controlled in-app boundary	Draft PR #5679
3	#3149 - Token capability boundary	Ensure bearer credentials are accepted only on explicitly intended route families and cannot gain unrelated behavior through owner attribution	Draft PR #5680 (refreshes #3150)
4	#5675 - Companion runtime and pairing removal	Stop minting app-specific credentials and remove the /api/companion/* router, package, and tests without guessing at destructive token migration	Draft PR #5681 after #5680
5	Owner-attribution audit	Remove only companion-specific identity behavior that is no longer required while preserving deliberately supported generic API ownership	Open a child only if current-dev evidence proves a separate code change is needed
6	Documentation and specification follow-up	Reconcile public documentation and implementation specifications only after the code boundary has landed on dev	Separate follow-up after implementation merges

Working rules:

• Treat this as stabilization and removal work, not a venue to design or promote a companion app.
• Preserve responsive browser and PWA support, generic API-token use cases with explicit capabilities, webhooks, and unrelated integrations.
• Keep each behavior change in one reviewable child issue and PR with current-dev reproduction or source evidence and focused regression coverage.
• Put any sensitive implementation detail through the repository's private security-reporting path rather than reproducing it publicly here.
• Run deep review rounds after each branch is implementation-ready, fix findings, and perform one final exact-head review before asking maintainers to merge a draft PR.
• Link candidate PRs to their focused child issue and add child issues to this tracker.
• Do not combine this work with a general authentication rewrite, frontend rewrite, or repository-wide cleanup.

Acceptance criteria:

• App-specific credential minting and /api/companion/* behavior are absent from the final current-dev tree.
• Credentials are constrained by explicit capabilities and route intent rather than implicit owner equivalence.
• Existing tokens can be reviewed and revoked through the normal operator path without guessing from a mutable display name.
• Generic API, webhook, responsive web, and PWA behavior remain covered and unchanged unless a focused child explicitly says otherwise.
• Every implementation slice is independently reviewable and receives a clean final exact-head review.
• Documentation and specifications are reconciled separately after the implementation order is settled and merged.

Alternatives Considered

Keeping the bridge and continuing the open feature series was rejected for now because it would commit core to an external app contract before a maintainer-owned product and security decision.

Expanding the bridge first and auditing capabilities later was rejected because it increases the surface that must be reviewed and retired.

Removing generic API or mobile-browser support was rejected because those are independent capabilities and do not require an app-specific compatibility layer.

A broad authentication or application rewrite was rejected because it would make this stabilization work harder to validate and merge.

Prior Art / Related Issues

• Proposal: mobile companion app (thin remote) + /api/companion/* bridge #3244 is the open companion-app proposal that asks maintainers to decide whether the integration belongs in-tree.
• Companion bridge (1/4): read-only ping/info/owner-scoped models + tests #863, Companion bridge (2/4): token-owner session attribution + tests #871, and Companion bridge (3/4): admin-only device pairing (mint on POST, CSRF-safe) + tests #877 introduced the currently merged bridge, owner attribution, and pairing path.
• fix(companion): require chat scope for model inventory #4319 added a later scope check to the companion model inventory.
• Harden API token route capabilities #3150 is an open draft candidate for the broader API-token route-capability boundary and should be evaluated before opening overlapping work.
• Auth middleware misclassifies routes below an ASGI root path #5677 tracks the current mounted-path mismatch between middleware policy and Starlette routing.
• Codex Cookbook bearer routes have an inconsistent admin boundary #5676 tracks retirement of the inconsistent Cookbook bearer surface found while validating that boundary.
• Proposal: Companion Access Center, show which URL is reachable before pairing #1970, Surface mobile-app pairing in the web Settings UI (no terminal needed) #2584, Companion mobile-feature bridge: owner-scoped endpoints for the native app (documents, gallery, calendar, email, …) #2666, Companion: deliver owner-scoped lifecycle events to a paired phone as push notifications #2729, and the open companion PR series are related backlog to route through this tracker once the exact disposition is confirmed.

Are you willing to implement this?

Yes — I can open a PR