@rubytech/create-maxy-code 0.1.465 → 0.1.467

package/payload/platform/plugins/google/references/auth.md

@@ -0,0 +1,345 @@
+# Google Auth Reference
+
+## Status: Phase 0 spike — documentation-backed, not yet token-verified
+
+This is the Phase 0 deliverable: the OAuth-flow verdict for a per-account
+**Google Calendar** plugin on a headless install where the operator consents from a phone
+over WhatsApp, with no browser on the box.
+
+Scope note: this plugin is **calendar-only**. Mail stays on the `email` plugin's IMAP/SMTP
+path; there is no Gmail API surface. That choice is deliberate and it is what keeps this
+plugin out of Google's restricted-scope security review (see
+["Verification"](#verification-the-light-kind-not-the-security-assessment)). Contacts
+(People API, read-only) is a possible later addition on the same footing but is not in this
+plugin.
+
+Every claim below is grounded in Google's **published** behaviour, cited inline. What is
+**not** yet done is the live token test the task requires: a real token issued (or refused)
+by an actual Google OAuth client for the Calendar scope. Until that runs
+(["Live test that closes the Phase 0 gate"](#live-test-that-closes-the-phase-0-gate)),
+this document is a prediction, not a proof. Do **not** build the register/register-poll
+path against it before the live test confirms the verdict.
+
+What is decided from published behaviour:
+
+- The **device-authorization grant is rejected** for this plugin. Google's device flow
+  serves only a fixed allowlist of scopes; Calendar is not on it.
+- The flow is therefore an **operator-assisted authorization-code (PKCE) flow**, and it
+  needs a redirect method, because Google's out-of-band ("paste the code") flow is fully
+  blocked.
+- The recommended redirect method is a **hosted HTTPS callback on the brand's existing
+  Cloudflare tunnel domain** (a "Web application" client), with a **loopback + manual
+  code relay** (a "Desktop app" client) as the secret-less fallback.
+- **Verification is the light kind.** Calendar is a *sensitive* scope, not a *restricted*
+  one, so a brand's app needs only OAuth brand/consent-screen verification, never the
+  annual third-party security assessment.
+
+This diverges from Outlook on one axis: Outlook's device-code flow is secret-less, and the
+recommended Google flow holds a per-brand client secret. That divergence is forced by
+Google, not chosen; the reasoning is below.
+
+---
+
+## Verdict 1: device-code is rejected (scope allowlist)
+
+Outlook uses Microsoft's `/devicecode` grant so the operator enters a code on their own
+phone and never needs a browser on the box. The first question for Google was whether the
+same grant works.
+
+It does not, for the Calendar scope. Google's OAuth 2.0 flow for TV and limited-input
+devices is supported only for a fixed allowlist. Verbatim from Google's documentation
+([OAuth 2.0 for TV and Limited-Input Device Applications](https://developers.google.com/identity/protocols/oauth2/limited-input-device)):
+
+> The OAuth 2.0 flow for devices is supported only for the following scopes:
+>
+> **OpenID Connect, Google Sign-In:** `email`, `openid`, `profile`
+> **Drive API:** `https://www.googleapis.com/auth/drive.appdata`, `https://www.googleapis.com/auth/drive.file`
+> **YouTube API:** `https://www.googleapis.com/auth/youtube`, `https://www.googleapis.com/auth/youtube.readonly`
+
+The Calendar scope (`https://www.googleapis.com/auth/calendar`) is absent. A device-flow
+authorization request that includes it is refused. The device-code grant cannot represent
+this plugin's calendar.
+
+**The live test still owes the verbatim refusal.** The task's gate is a real refusal from a
+real client, not this allowlist. The live test below issues a `/device/code` request for
+the Calendar scope against a real client of type "TV and Limited Input" and records the
+exact error body. Expected: a `403`/`invalid_scope`-class refusal naming the scope. The
+allowlist above is the reason to expect it; the recorded response is the proof.
+
+## Verdict 2: OOB ("paste a code") is dead — a redirect is mandatory
+
+The other headless-friendly pattern is out-of-band: Google shows the operator a code on a
+web page, the operator pastes it back, no redirect URI. That flow is gone. Google blocked
+new OOB use on 28 Feb 2022 and blocked all existing clients on 31 Jan 2023
+([OOB migration guide](https://developers.google.com/identity/protocols/oauth2/resources/oob-migration);
+[Google Developers Blog](https://developers.googleblog.com/making-google-oauth-interactions-safer-by-using-more-secure-oauth-flows/)).
+A `redirect_uri=urn:ietf:wg:oauth:2.0:oob` request is refused.
+
+So consent must land on a real `redirect_uri`. For an installed/desktop app Google's named
+replacement is the **loopback IP redirect** (`http://127.0.0.1:<port>` or
+`http://localhost:<port>`), and it "requires you to be listening on a local web server
+... to receive the authorization code" (OOB migration guide). Google's migration guidance
+covers mobile, Chrome, web, and desktop clients; it gives **no** cross-device pattern for
+a headless box where consent happens on a separate phone. That gap is the design problem
+this plugin has to solve itself.
+
+## Verdict 3: the flow — operator-assisted authorization-code (PKCE)
+
+Because the operator's browser is on a phone and the plugin is on the box, the redirect
+that carries the `code` and the process that exchanges it live on different machines. Two
+concrete flows bridge that. The recommendation is Option B primary, Option A as the
+secret-less fallback.
+
+### Option B (recommended): hosted HTTPS callback on the brand tunnel domain
+
+Client type **Web application**. A stable authorized redirect URI on the install's existing
+Cloudflare **public** host, served by the always-running `platform/ui` server (the same
+process that runs the Outlook auto-poll dispatcher):
+
+```
+https://<brand-public-host>/api/google/oauth/callback
+```
+
+**The `/api/` prefix is mandatory, not cosmetic.** The public host is not a general web
+server: it admits only an allowlist of path prefixes and 404s everything else
+(`platform/ui/server/public-host-gate.ts`, `PUBLIC_ALLOWED_PREFIXES`). A bare
+`/google/oauth/callback` would 404 before reaching any route. Phase 2 must add
+`/api/google/` to that allowlist in the same commit as the callback route.
+
+The public host is also the correct *class* of host, and there is an exact in-repo
+precedent. QuickBooks already solved this identical problem, and the allowlist records why:
+
+> QuickBooks OAuth consent callback. Intuit redirects the operator's browser here with no
+> admin cookie; the route authenticates by validating the OAuth `state` nonce, not the
+> remote-auth gate (same model as `/api/telegram/`).
+
+Google's redirect has the same shape: the client's phone browser arrives with no admin
+cookie, so the route authenticates on the `state` nonce rather than the remote-auth gate.
+Mirror `/api/quickbooks/` rather than inventing a new pattern.
+
+```
+operator (phone)                     plugin / platform-ui (box)                 Google
+   |                                        |                                     |
+   | google-account-register                |                                     |
+   |--------------------------------------->| build PKCE (verifier+challenge),    |
+   |                                        | state; write pending-oauth.enc      |
+   |                                        | build consent URL (access_type=     |
+   |                                        |   offline, prompt=consent, calendar |
+   |                                        |   scope, redirect=<tunnel>/cb)      |
+   | { status:"pending", consentUrl }       |                                     |
+   |<---------------------------------------|                                     |
+   | open consentUrl on phone, sign in,     |                                     |
+   | consent ------------------------------------------------------------------->  |
+   |                                        | GET /api/google/oauth/callback?code&state <-- redirect
+   |                                        | verify state, exchange code+verifier |
+   |                                        |   (+client secret) --------------->  |
+   |                                        | < tokens (access+refresh)            |
+   |                                        | GET userinfo → account email/id      |
+   |                                        | encrypt → accounts/<id>/tokens.enc   |
+   |                                        | clear pending                        |
+   | google-account-register-poll → { registered, email }                          |
+   |<---------------------------------------|                                     |
+```
+
+The operator sees a clean "connected, return to WhatsApp" page; the code is captured
+server-side, never relayed by hand. `register-poll` reports success from local state,
+exactly like Outlook's poll. This is the better ergonomic match for a non-technical
+operator on WhatsApp, which is the whole reason device-code was wanted.
+
+Cost: a Web-application client carries a **real client secret** and a per-brand authorized
+redirect URI. The secret is confidential and lives in the brand/account secret store, never
+bundled into the installer. This is the one divergence from Outlook.
+
+### Option A (fallback): loopback client + manual code relay
+
+Client type **Desktop app**, redirect `http://127.0.0.1:<port>`. No hosted endpoint, no
+per-brand redirect URI beyond the fixed loopback, and the installed-app secret Google
+issues for desktop clients is documented as non-confidential.
+
+The operator opens the consent URL on the phone and consents; Google redirects the phone
+browser to `http://localhost:<port>/?code=...`, which fails to load (nothing listens on the
+phone). The operator copies the `code` value out of the address bar of the failed page and
+sends it back via a `google-account-register-submit` tool; the plugin exchanges it with the
+stored PKCE verifier.
+
+Cost: extracting a `code` from a failed-load address bar on a phone is fragile — some mobile
+browsers hide the URL of a failed navigation. Use this only where a brand has no usable
+hosted callback. The live test measures whether this UX is acceptable before it is relied on.
+
+### Why the recommendation, and what the live test decides
+
+Option B wins on operator UX and robustness at the cost of a per-brand secret. Option A
+keeps provisioning minimal and secret-light at the cost of a fragile mobile step. The live
+test resolves the open question — that Option B's hosted callback round-trips a real token
+for the Calendar scope — before any register code is built. If the tunnel-hosted callback
+is not viable for a given brand, Option A is the recorded fallback.
+
+---
+
+## Client-id / secret model per brand
+
+One vendor-owned Google Cloud OAuth client per brand serves every install and every account
+on that brand, exactly as `outlookClientId` does. The client id ships as the brand default
+`brands/<brand>/brand.json#googleClientId`, stamped onto the session-manager unit env as
+`GOOGLE_CLIENT_ID` and inherited down the spawn chain (manager unit env → PTY → MCP child).
+
+Divergence from Outlook: the recommended Web-application flow (Option B) also needs a
+**client secret**. It ships **not** as a plaintext brand default but is held in the brand's
+secret store and stamped as `GOOGLE_CLIENT_SECRET` the same way Cloudflare tokens are held
+(never written to a project tree, never echoed). A brand that ships `googleClientId` empty
+has the plugin inert with an actionable signal (`clientIdConfigured=false`), register
+refuses, and no operator action makes it work until the vendor client exists — mirroring
+Outlook's inert behaviour.
+
+---
+
+## Vendor provisioning runbook (one-time per brand)
+
+Run once per brand to mint the client whose id goes in that brand's `brand.json` and whose
+secret goes in the brand secret store. Not an end-user step. Each brand is a separate
+follow-up once the plugin lands (mirroring Outlook 1479/1485).
+
+1. Sign in to the [Google Cloud console](https://console.cloud.google.com) with the brand's
+   Google account. Create (or select) one project named for the brand and its Google
+   integration, e.g. `SiteDesk Google`.
+2. Enable the **Google Calendar API** (APIs & Services → Library). That is the only API this
+   plugin calls.
+3. Configure the **OAuth consent screen**: user type **External**, app name and support
+   email set to the brand's, and add the single scope below. Publishing status starts at
+   **Testing** and moves to **In production** once brand verification is done (see below).
+4. Create the **OAuth client**:
+   - **Option B (recommended):** application type **Web application**. Add the authorized
+     redirect URI `https://<brand-public-host>/api/google/oauth/callback` (the `/api/`
+     prefix is required — see Option B above). Copy the **Client ID**
+     (→ `brand.json#googleClientId`) and **Client secret** (→ brand secret store as
+     `GOOGLE_CLIENT_SECRET`; never paste a secret into a chat transcript or the repo).
+   - **Option A (fallback):** application type **Desktop app**. Copy the **Client ID**.
+5. Set `googleClientId` in the brand's `brand.json` and re-bundle:
+   ```jsonc
+   // brands/<brand>/brand.json
+   "googleClientId": "<the Client ID copied above>"
+   ```
+
+### Scope
+
+One scope, chosen to match the Outlook calendar tool surface (read plus create, update,
+cancel, respond, free-busy), no broader:
+
+| Purpose | Scope | Class |
+|---|---|---|
+| Identity (email address, sign-in) | `openid`, `email`, `profile` | non-sensitive |
+| Calendar read + event create/update/cancel/respond/free-busy | `https://www.googleapis.com/auth/calendar` | sensitive |
+
+Notes:
+
+- `calendar` (full) is the simplest choice for read plus all the control operations. The
+  narrower alternative is `calendar.events` + `calendar.readonly` + `calendar.freebusy`; the
+  live test can confirm the narrower set is sufficient before Phase 2 fixes it. All Calendar
+  scopes are *sensitive*, not *restricted*, so the narrower choice does not change the
+  verification path.
+- A refresh token requires `access_type=offline` plus `prompt=consent` on the consent URL;
+  this is a request parameter, not a scope.
+
+### Verification: the light kind, not the security assessment
+
+The Calendar scope is **sensitive**, not restricted. Google requires a production app that
+uses sensitive scopes to pass OAuth **brand/consent-screen verification** (own the domain,
+Google reviews the app name, logo, and scope justification). It does **not** require the
+annual third-party security assessment — that applies only to *restricted* scopes such as
+the Gmail read/modify family, which this plugin does not use. Dropping the Gmail surface is
+exactly what keeps a brand off the expensive review.
+
+The two publishing states, and what each costs:
+
+- **Testing** (no verification): works immediately for up to **100 named test accounts**,
+  each of which sees the unverified-app warning and re-consents about **every 7 days**
+  (Google caps refresh-token lifetime while an app is in Testing). Fine for a pilot,
+  including the first `sitedesk-code` account.
+- **In production + brand-verified** (the light verification, no cost, no security firm,
+  typically days to a couple of weeks): the 100-account cap lifts, the warning is gone, and
+  refresh tokens are long-lived. This is the real deployment state and the target for each
+  brand. Start it early per brand, because Google's review is the slow part.
+
+---
+
+## Token store and pending-state layout (informs Phase 1/2, not built here)
+
+The store mirrors Outlook's per-account encrypted layout: one AES-256-CBC `.key` per
+account, `tokens.enc` under `accounts/<id>/`, mode 0700 dirs and 0600 files, atomic
+temp+rename writes. This plugin is one Google account per registration, so there is no
+multi-mailbox nesting to mirror.
+
+```
+data/accounts/<accountId>/secrets/google/
+├── .key                          # 32 random bytes, base64 — per-account AES-256-CBC key
+├── accounts/
+│   └── <userId>/tokens.enc       # AES-256-CBC token JSON blob per registered Google account
+└── pending-oauth.enc             # transient: PKCE verifier + state between register and callback/submit
+```
+
+Two divergences from Outlook are required and must be honoured in Phase 2:
+
+- **Pending state is a PKCE verifier + `state`, not a device code.** Register writes it;
+  the callback (Option B) or `register-submit` (Option A) reads and clears it. Single-slot
+  per account, refuses a second concurrent register with an `in-progress` signal, cleared
+  on any terminal outcome.
+- **The concurrent-refresh race must not be reproduced.** Outlook's token writer used a
+  fixed `.tmp` name and could wipe valid tokens when two refreshes raced. The
+  Google writer uses a unique temp name per write and a refresh catch that never clears
+  valid tokens on an IO error. A losing concurrent writer must not wipe credentials.
+
+Refresh triggers automatically within 5 minutes of access-token expiry, mirroring Outlook.
+The 7-day Testing-status refresh-token expiry above is separate: it is Google forcing
+re-consent until the brand is verified, not a refresh failure, and the health signal must
+name it distinctly.
+
+---
+
+## Live test that closes the Phase 0 gate
+
+Run this once a real Google OAuth client exists, before building the register path. It
+converts the predictions above into recorded facts.
+
+**Prerequisite: add test users.** A newly created client sits in **Testing**, where consent
+is refused for anyone not on the consent screen's test-user list — including the operator.
+Add the testing Google account (and any client account used for the trial) before attempting
+step 2, or consent dead-ends with an access-denied screen that looks like a flow bug.
+
+**The round-trip does not require the callback route to exist.** The route is Phase 2 code,
+and Phase 0 must not build it. Google still redirects the browser to the callback URL with
+`?code=...` in the query string; the page 404s (the allowlist entry is not added yet) but
+the address bar carries the code. Copying it from there and exchanging it by hand proves
+everything the gate asks about, with no plugin code written.
+
+1. **Authorization-code round-trip (Verdict 3, Option B) — the load-bearing step.** With the
+   Web-application client, open the consent URL for the Calendar scope with
+   `access_type=offline` and `prompt=consent`, consent as a listed test user, then copy the
+   `code` value from the address bar of the 404'd callback page. Exchange it against
+   `https://oauth2.googleapis.com/token` with the client id, client secret, the same
+   `redirect_uri`, and `grant_type=authorization_code`. Confirm the response carries a
+   **refresh token** and the granted `scope` includes the Calendar scope. Run this on the
+   device, where the client secret already lives; never paste the secret into a transcript.
+   Record the granted scope and the presence of a refresh token (never the tokens
+   themselves).
+2. **Device-code refusal (Verdict 1) — optional, confirmatory only.** Verdict 1 already
+   rests on Google's published allowlist, which does not list any Calendar scope. Confirming
+   it empirically needs a *second*, throwaway client of type "TV and Limited Input", since a
+   Web-application client cannot exercise the device grant. Worth doing only if the recorded
+   refusal is wanted for the file; it changes no decision, because step 1 succeeding already
+   establishes the flow being built.
+3. **Narrow-scope check (optional).** Repeat step 1 with `calendar.events` +
+   `calendar.readonly` + `calendar.freebusy` instead of `calendar`, and confirm event
+   create/update/cancel/respond/free-busy all work, to decide the narrower scope for Phase 2.
+
+Paste the recorded outcome into this section. Once step 1 is recorded, the Phase 0 gate is
+met and Phases 1–2 (the plugin build) proceed against the confirmed flow.
+
+### Provisioned clients
+
+| Brand | Client type | Redirect URI | Client ID | Status |
+|---|---|---|---|---|
+| `sitedesk-code` | Web application | `https://public.sitedesk.online/api/google/oauth/callback` | `1032860640027-p61l59fnog4mad5o7grginpaps9jnu8c.apps.googleusercontent.com` | Testing — test users pending, round-trip not yet run |
+
+The public host was confirmed live and routing to the `platform/ui` server (it serves the
+brand's public page). Secrets are not recorded here; the client secret lives only in the
+brand secret store on the device.

package/payload/platform/services/claude-session-manager/dist/http-server.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"http-server.d.ts","sourceRoot":"","sources":["../src/http-server.ts"],"names":[],"mappings":"AAqBA,OAAO,EAAE,IAAI,EAAE,MAAM,MAAM,CAAA;AAgB3B,OAAO,EAkBL,KAAK,SAAS,EAEf,MAAM,kBAAkB,CAAA;AAoCzB,OAAO,KAAK,EAAE,SAAS,EAAyB,MAAM,iBAAiB,CAAA;AAEvE,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,yBAAyB,CAAA;AAC1D,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,wBAAwB,CAAA;AAE3D,OAAO,EAAE,kBAAkB,EAAE,MAAM,2BAA2B,CAAA;AAC9D,OAAO,EAAE,cAAc,EAAE,MAAM,uBAAuB,CAAA;AACtD,OAAO,EAAE,mBAAmB,EAAE,MAAM,4BAA4B,CAAA;AAChE,OAAO,EAAE,oBAAoB,EAAE,MAAM,6BAA6B,CAAA;AAyFlE,eAAO,MAAM,kBAAkB,QAA2B,CAAA;AAS1D,eAAO,MAAM,4BAA4B,QAAS,CAAA;AAIlD,MAAM,WAAW,QAAS,SAAQ,IAAI,CAAC,SAAS,EAAE,gBAAgB,GAAG,SAAS,CAAC;IAC7E;;qEAEiE;IACjE,MAAM,CAAC,EAAE,MAAM,CAAA;IACf,OAAO,EAAE,SAAS,CAAA;IAClB,WAAW,EAAE,MAAM,CAAA;IACnB,iBAAiB,EAAE,MAAM,CAAA;IACzB,kBAAkB,EAAE,WAAW,CAAA;IAC/B,eAAe,EAAE,aAAa,CAAA;IAC9B;kFAC8E;IAC9E,WAAW,EAAE,kBAAkB,CAAA;IAC/B;;gFAE4E;IAC5E,cAAc,EAAE,cAAc,CAAA;IAC9B;;;6BAGyB;IACzB,mBAAmB,CAAC,EAAE,mBAAmB,CAAA;IACzC;;;sCAGkC;IAClC,oBAAoB,CAAC,EAAE,oBAAoB,CAAA;IAC3C;;gFAE4E;IAC5E,gBAAgB,CAAC,EAAE,MAAM,CAAA;CAC1B;AAsFD;;;;;;mEAMmE;AACnE,wBAAgB,kBAAkB,CAAC,SAAS,EAAE,MAAM,GAAG,MAAM,EAAE,CAiC9D;AAMD;;;;;;iBAMiB;AACjB,wBAAgB,yBAAyB,CAAC,SAAS,EAAE,MAAM,EAAE,SAAS,EAAE,MAAM,GAAG,OAAO,CAmCvF;AAID;;;;;;yBAMyB;AACzB,wBAAgB,cAAc,CAAC,SAAS,EAAE,MAAM,GAAG,OAAO,CAiCzD;AAwCD,wBAAgB,eAAe,CAAC,aAAa,EAAE,MAAM,EAAE,YAAY,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,GAAG,MAAM,EAAE,CAEpG;AAgBD,wBAAgB,oBAAoB,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM,CAE1D;AAUD,wBAAgB,2BAA2B,CAAC,IAAI,EAAE,MAAM,GAAG,IAAI,GAAG,MAAM,CAMvE;AAMD,wBAAgB,gBAAgB,CAC9B,SAAS,EAAE,MAAM,GAAG,IAAI,EACxB,OAAO,EAAE,MAAM,EACf,YAAY,EAAE,MAAM,EACpB,YAAY,EAAE,MAAM,EACpB,QAAQ,EAAE,MAAM,GAAG,IAAI,GACtB,MAAM,CAER;AAkCD,wBAAgB,0BAA0B,CAAC,KAAK,EAAE,MAAM,EAAE,EAAE,SAAS,EAAE,MAAM,GAAG,MAAM,GAAG,IAAI,CAe5F;AAiGD,wBAAgB,6BAA6B,CAAC,IAAI,EAAE,QAAQ,EAAE,SAAS,EAAE,MAAM,EAAE,OAAO,EAAE,OAAO,GAAG,IAAI,CASvG;AAUD,wBAAgB,6BAA6B,CAC3C,IAAI,EAAE,QAAQ,EACd,QAAQ,EAAE,MAAM,EAChB,SAAS,EAAE,MAAM,EACjB,OAAO,EAAE,OAAO,EAChB,gBAAgB,EAAE,OAAO,GACxB,IAAI,CA4BN;AA6DD;;;kEAGkE;AAClE,MAAM,MAAM,OAAO,GAAG,IAAI,GAAG;IAC3B,2BAA2B,CAAC,SAAS,EAAE,MAAM,GAAG,IAAI,CAAA;IACpD;;;+CAG2C;IAC3C,sBAAsB,CAAC,SAAS,EAAE,MAAM,GAAG,IAAI,CAAA;CAChD,CAAA;AA8CD,wBAAgB,YAAY,CAAC,IAAI,EAAE,QAAQ,GAAG,OAAO,CA+gGpD"}
+{"version":3,"file":"http-server.d.ts","sourceRoot":"","sources":["../src/http-server.ts"],"names":[],"mappings":"AAqBA,OAAO,EAAE,IAAI,EAAE,MAAM,MAAM,CAAA;AAgB3B,OAAO,EAkBL,KAAK,SAAS,EAEf,MAAM,kBAAkB,CAAA;AAoCzB,OAAO,KAAK,EAAE,SAAS,EAAyB,MAAM,iBAAiB,CAAA;AAEvE,OAAO,KAAK,EAAE,WAAW,EAAE,MAAM,yBAAyB,CAAA;AAC1D,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,wBAAwB,CAAA;AAE3D,OAAO,EAAE,kBAAkB,EAAE,MAAM,2BAA2B,CAAA;AAC9D,OAAO,EAAE,cAAc,EAAE,MAAM,uBAAuB,CAAA;AACtD,OAAO,EAAE,mBAAmB,EAAE,MAAM,4BAA4B,CAAA;AAChE,OAAO,EAAE,oBAAoB,EAAE,MAAM,6BAA6B,CAAA;AAyFlE,eAAO,MAAM,kBAAkB,QAA2B,CAAA;AAS1D,eAAO,MAAM,4BAA4B,QAAS,CAAA;AAIlD,MAAM,WAAW,QAAS,SAAQ,IAAI,CAAC,SAAS,EAAE,gBAAgB,GAAG,SAAS,CAAC;IAC7E;;qEAEiE;IACjE,MAAM,CAAC,EAAE,MAAM,CAAA;IACf,OAAO,EAAE,SAAS,CAAA;IAClB,WAAW,EAAE,MAAM,CAAA;IACnB,iBAAiB,EAAE,MAAM,CAAA;IACzB,kBAAkB,EAAE,WAAW,CAAA;IAC/B,eAAe,EAAE,aAAa,CAAA;IAC9B;kFAC8E;IAC9E,WAAW,EAAE,kBAAkB,CAAA;IAC/B;;gFAE4E;IAC5E,cAAc,EAAE,cAAc,CAAA;IAC9B;;;6BAGyB;IACzB,mBAAmB,CAAC,EAAE,mBAAmB,CAAA;IACzC;;;sCAGkC;IAClC,oBAAoB,CAAC,EAAE,oBAAoB,CAAA;IAC3C;;gFAE4E;IAC5E,gBAAgB,CAAC,EAAE,MAAM,CAAA;CAC1B;AAsFD;;;;;;mEAMmE;AACnE,wBAAgB,kBAAkB,CAAC,SAAS,EAAE,MAAM,GAAG,MAAM,EAAE,CAiC9D;AAMD;;;;;;iBAMiB;AACjB,wBAAgB,yBAAyB,CAAC,SAAS,EAAE,MAAM,EAAE,SAAS,EAAE,MAAM,GAAG,OAAO,CAmCvF;AAID;;;;;;yBAMyB;AACzB,wBAAgB,cAAc,CAAC,SAAS,EAAE,MAAM,GAAG,OAAO,CAiCzD;AAwCD,wBAAgB,eAAe,CAAC,aAAa,EAAE,MAAM,EAAE,YAAY,EAAE,MAAM,EAAE,KAAK,EAAE,MAAM,GAAG,MAAM,EAAE,CAEpG;AAgBD,wBAAgB,oBAAoB,CAAC,KAAK,EAAE,MAAM,GAAG,MAAM,CAE1D;AAUD,wBAAgB,2BAA2B,CAAC,IAAI,EAAE,MAAM,GAAG,IAAI,GAAG,MAAM,CAMvE;AAMD,wBAAgB,gBAAgB,CAC9B,SAAS,EAAE,MAAM,GAAG,IAAI,EACxB,OAAO,EAAE,MAAM,EACf,YAAY,EAAE,MAAM,EACpB,YAAY,EAAE,MAAM,EACpB,QAAQ,EAAE,MAAM,GAAG,IAAI,GACtB,MAAM,CAER;AAkCD,wBAAgB,0BAA0B,CAAC,KAAK,EAAE,MAAM,EAAE,EAAE,SAAS,EAAE,MAAM,GAAG,MAAM,GAAG,IAAI,CAe5F;AAiGD,wBAAgB,6BAA6B,CAAC,IAAI,EAAE,QAAQ,EAAE,SAAS,EAAE,MAAM,EAAE,OAAO,EAAE,OAAO,GAAG,IAAI,CASvG;AAUD,wBAAgB,6BAA6B,CAC3C,IAAI,EAAE,QAAQ,EACd,QAAQ,EAAE,MAAM,EAChB,SAAS,EAAE,MAAM,EACjB,OAAO,EAAE,OAAO,EAChB,gBAAgB,EAAE,OAAO,GACxB,IAAI,CA4BN;AA6DD;;;kEAGkE;AAClE,MAAM,MAAM,OAAO,GAAG,IAAI,GAAG;IAC3B,2BAA2B,CAAC,SAAS,EAAE,MAAM,GAAG,IAAI,CAAA;IACpD;;;+CAG2C;IAC3C,sBAAsB,CAAC,SAAS,EAAE,MAAM,GAAG,IAAI,CAAA;CAChD,CAAA;AA8CD,wBAAgB,YAAY,CAAC,IAAI,EAAE,QAAQ,GAAG,OAAO,CAohGpD"}

package/payload/platform/services/claude-session-manager/dist/http-server.js

@@ -3043,6 +3043,11 @@ export function buildHttpApp(deps) {
             brandedNeo4jUri: process.env.NEO4J_URI ?? '',
             brandedNeo4jPassword: process.env.NEO4J_PASSWORD ?? '',
             sliceToken,
+            // Task 1764 — stamp CLAUDE_CODE_REMOTE_ENVIRONMENT_TYPE for operator
+            // surfaces so SendUserFile survives a bridgeless resume, but never for
+            // role='public' spawns (the public session-end review), which Task 1724
+            // scoped out. Mirrors pty-spawner's `role !== 'public'` exclusion.
+            remoteControl: rcRole !== 'public',
             // Task 1466 — deliver the computed house-admin scope into the child env
             // (and thus its installed-plugin MCP children); null on non-house / public
             // / specialist spawns leaves the var unset.