scriptscat · cyfung1031 · Sep 16, 2026 · Sep 16, 2026 · Sep 16, 2026 · Sep 17, 2026
diff --git a/AGENTS.md b/AGENTS.md
@@ -232,6 +232,13 @@ Service Worker (src/service_worker.ts)
 > SW → Offscreen uses `ServiceWorkerMessageSend` (`clients.matchAll()` + `postMessage`) on Chrome and
 > `EventPageOffscreenManager` on Firefox MV3; Offscreen replies to SW over `ExtensionMessage`. `WindowMessage`
 > is the Offscreen ↔ Sandbox channel.
+>
+> USER_SCRIPT content and MAIN inject runtimes normally use native extension channels directly to the SW.
+> The `scripting` bundle is a document-start extension content script registered per matching frame. It runs a
+> page-bridge runtime and is a supporting per-document helper rather than a separate service/background context in
+> this five-context model. Those bridges carry the content bootstrap handoff, MAIN bootstrap/fallback and runtime update packets,
+> synchronous DOM handles, and the whitelisted `external.Scriptcat` API. When MAIN GM RPC falls back through
+> `PageMessage`, the scripting runtime validates its execution handle and grant before forwarding it to the SW.
 
 - **Service Worker** — central hub for script CRUD, Chrome APIs, permission verification, resource caching, and message routing.
 - **Content** — bridges SW and inject script.
@@ -244,9 +251,13 @@ Sandbox.
 
 ### Message Passing (`packages/message/`)
 
-`ExtensionMessage` (chrome.runtime — SW ↔ Content / Inject / Offscreen), `WindowMessage` (postMessage — Offscreen ↔
-Sandbox), `ServiceWorkerMessageSend` (`clients.matchAll()` + `postMessage` — SW → Offscreen on Chrome),
-`CustomEventMessage` (CustomEvent — Content ↔ Inject), and `MessageQueue` (cross-context broadcast).
+`ExtensionMessage` (chrome.runtime — SW ↔ Content / Inject / Offscreen), `PageMessage` (`window.postMessage` —
+scripting ↔ Inject page bridge, including validated MAIN RPC fallback), `CustomEventMessage` (CustomEvent —
+bootstrap handoff and DOM handles),
+`WindowMessage` (`postMessage` — Offscreen ↔ Sandbox), `ServiceWorkerMessageSend` (`clients.matchAll()` +
+`postMessage` — SW → Offscreen on Chrome), and `MessageQueue` (cross-context broadcast). Page-visible bridges do
+not establish an authenticated extension origin; MAIN requests relayed through `PageMessage` must pass the
+`PageRpcRegistry` checks before forwarding.
 
 ### Service & Data Layers
 

diff --git a/docs/architecture.md b/docs/architecture.md
@@ -77,6 +77,16 @@ Three ideas explain almost everything in the codebase:
          inject, and sandbox don't hold a MessageQueue instance.
 ```
 
+The diagram compresses the page-facing routes: USER_SCRIPT content and MAIN inject runtimes also connect directly
+to the Service Worker through native extension channels on the preferred path. The `scripting` bundle is a
+document-start extension content script registered per matching frame; it runs a page-bridge runtime and is a
+supporting per-document helper rather than a separate service/background context in this five-context model.
+`CustomEventMessage` carries the content bootstrap
+handoff and synchronous DOM handles; `PageMessage` carries MAIN bootstrap/fallback traffic, runtime event/value
+updates, and the whitelisted `external.Scriptcat` API. When MAIN GM RPC uses the page bridge fallback, the scripting
+runtime validates the execution handle and grant before forwarding it to the Service Worker; the page bridge
+itself is not an authenticated extension origin.
+
 ---
 
 ## The Five Contexts (Process Model)
@@ -86,8 +96,8 @@ Each context is a separate bundle (see [Build pipeline & manifest](./references/
 | Context | Entry | Realm / capabilities | Bootstraps |
 |---|---|---|---|
 | **Service Worker** | [`src/service_worker.ts`](../src/service_worker.ts) | No DOM. Owns `chrome.*` privileged APIs, storage, permissions, routing. | `ExtensionMessage(true)` → `Server("serviceWorker")` + `MessageQueue` → `ServiceWorkerManager` |
-| **Content** | [`src/content.ts`](../src/content.ts) | Isolated content-script world. Bridges SW and the page. | `CustomEventMessage` channel to inject + `Server("content")` → `ScriptRuntime` |
-| **Inject** | [`src/inject.ts`](../src/inject.ts) | Page (`MAIN`) world. Has `unsafeWindow`; runs page userscripts. | `CustomEventMessage` to content + `Server("inject")` |
+| **Content** | [`src/content.ts`](../src/content.ts) | `USER_SCRIPT` world. Receives a document bootstrap token through the page-side bridge, then uses a native extension channel for script loading, GM RPC, value updates, and callbacks. Dedicated USER_SCRIPT listeners are used when available; otherwise the regular port is token-bound. | `ExtensionMessage` + native callback port → `Server("content")` → `ScriptRuntime`; `CustomEventMessage` for bootstrap handoff and DOM handles |
+| **Inject** | [`src/inject.ts`](../src/inject.ts) | Page (`MAIN`) world. Has `unsafeWindow`; runs page userscripts. | Native extension port for the preferred GM RPC path; `PageMessage` for bootstrap/fallback, whitelisted external API, and validated GM RPC fallback; `CustomEventMessage` for synchronous DOM handles |
 | **Offscreen** | [`src/offscreen.ts`](../src/offscreen.ts) | DOM-capable background page (Blobs, clipboard, DOM scraping, local storage). | `ExtensionMessage()` + `WindowMessage(window, sandbox)` → `OffscreenManager` |
 | **Sandbox** | [`src/sandbox.ts`](../src/sandbox.ts) | `sandbox`ed iframe inside offscreen. Evaluates background/scheduled scripts; runs cron. | `WindowMessage(window, parent)` + `Server("sandbox")` → `SandboxManager` |
 
@@ -167,8 +177,9 @@ communication styles** over **several transports**.
 
 | Class | File | Connects | Underlying API |
 |---|---|---|---|
-| `ExtensionMessage` | [`extension_message.ts`](../packages/message/extension_message.ts) | SW ↔ Content / Inject / Offscreen | `chrome.runtime.sendMessage` / `onConnect` (+ `onUserScript*` on Firefox) |
-| `CustomEventMessage` | [`custom_event_message.ts`](../packages/message/custom_event_message.ts) | Content ↔ Inject | DOM `CustomEvent` dispatch (bypasses page tampering) |
+| `ExtensionMessage` | [`extension_message.ts`](../packages/message/extension_message.ts) | SW ↔ Content / Inject / Offscreen | `chrome.runtime.sendMessage` / `onConnect`; browser-identified USER_SCRIPT messages are action-gated, and regular-port fallbacks are token-bound |
+| `PageMessage` | [`page_message.ts`](../packages/message/page_message.ts) | `scripting` ↔ Inject | `window.postMessage`; page-visible MAIN bootstrap/fallback, runtime updates, whitelisted external API, and GM RPC fallback validated by `PageRpcRegistry` |
+| `CustomEventMessage` | [`custom_event_message.ts`](../packages/message/custom_event_message.ts) | Content ↔ `scripting` page helper | DOM `CustomEvent`; bootstrap handoff and synchronous DOM references, not privileged GM RPC |
 | `WindowMessage` | [`window_message.ts`](../packages/message/window_message.ts) | Offscreen ↔ Sandbox | `window.postMessage` |
 | `ServiceWorkerMessageSend` | [`window_message.ts`](../packages/message/window_message.ts) | SW → Offscreen (Chrome) | `clients.matchAll()` + `postMessage` |
 | `MessageQueue` | [`message_queue.ts`](../packages/message/message_queue.ts) | Broadcast among the contexts that instantiate it — SW, Offscreen, UI pages | `chrome.runtime.sendMessage` + local `EventEmitter3` |

diff --git a/docs/references/architecture-agent.md b/docs/references/architecture-agent.md
@@ -98,6 +98,34 @@ The Agent subsystem does not use one persistence pattern; pick by data shape, ma
   attachments), `AgentTaskRunRepo` (task run history), `SkillRepo` (skill `.md`/script bundles).
 - `MCPServerRepo` (`Repo<T>`) — MCP server configs.
 
+## Userscript resource ownership
+
+The `CAT.agent.*` APIs are granted per script, but a grant alone does not decide which persisted resources that
+script can access. The service-worker GM handlers take the caller identity from `request.script.uuid` and pass it
+to the Agent services; they do not use a caller-supplied `scriptUuid` as the authority.
+
+- **Conversations** created by a script persist `ownerScriptUuid`. Script reads, chats, attaches, and mutations
+  check that owner. UI and legacy conversations without an owner remain available to the extension UI but are not
+  visible to script callers. Ephemeral chats are not persisted conversations.
+- **Tasks** created by a script persist `ownerScriptUuid`; script list/get/update/delete/enable/run/history
+  operations are scoped to that owner. For compatibility, a legacy event task without an owner remains visible
+  only to the script named by `sourceScriptUuid`.
+- **DOM monitors** are scoped to the script UUID supplied by the service-worker GM handler and to the tab. A
+  script caller cannot peek, stop, or replace a monitor owned by another script.
+- **Attachments** live in the shared OPFS workspace and do not carry owner metadata themselves. Before
+  `CAT.agent.opfs.readAttachment` returns a file, `AgentChatRepo` verifies that a persisted message references
+  it from a conversation owned by the calling script. A guessed ID or a reference borrowed from another script's
+  conversation is insufficient.
+
+The checks are implemented in [`gm_agent.ts`](../../src/app/service/service_worker/gm_api/gm_agent.ts),
+[`gm_agent_dom.ts`](../../src/app/service/service_worker/gm_api/gm_agent_dom.ts),
+[`gm_agent_task.ts`](../../src/app/service/service_worker/gm_api/gm_agent_task.ts),
+[`chat_service.ts`](../../src/app/service/agent/service_worker/chat_service.ts),
+[`task_service.ts`](../../src/app/service/agent/service_worker/task_service.ts),
+[`background_session_manager.ts`](../../src/app/service/agent/service_worker/background_session_manager.ts),
+[`opfs_service.ts`](../../src/app/service/agent/service_worker/opfs_service.ts), and
+[`dom_cdp.ts`](../../src/app/service/agent/service_worker/dom_cdp.ts).
+
 ## Page / offscreen / sandbox delegation and permission boundaries
 
 - **Content (`src/app/service/content/gm_api/cat_agent.ts`)** exposes the `CAT.agent.*` API to user scripts —
@@ -120,7 +148,8 @@ The Agent subsystem does not use one persistence pattern; pick by data shape, ma
     uses CDP; a background (non-active) tab tries CDP first and falls back to `chrome.tabs.captureVisibleTab`
     on failure; an active tab with no selector uses `chrome.tabs.captureVisibleTab` directly.
   - **Tab monitoring** (`startMonitor`/`stopMonitor`/`peekMonitor`) is unconditionally CDP-based — there is no
-    non-CDP path for it at all.
+    non-CDP path for it at all. A monitor is scoped to its tab and initiating script; other scripts cannot
+    inspect, stop, or replace it.
 
   CDP attaches the debugger to a tab and carries the extra permission/user-visible-banner implications that
   come with `chrome.debugger`; how often that applies depends on which action you're looking at, not a single

diff --git a/docs/references/architecture-execution.md b/docs/references/architecture-execution.md
@@ -24,12 +24,12 @@ go through a controlled context object instead of the page's real globals:
 Key points:
 
 - `with(arguments[0]||this.$)` makes every bare identifier resolve against the GM context first. The context is
-  a `Proxy` that intercepts reads, so the script sees `unsafeWindow`, the granted `GM_*` functions, and a
-  controlled view of globals — not the raw page scope.
+  a descriptor-based pseudo-window that projects `unsafeWindow`, the granted `GM_*` functions, and a controlled
+  view of globals — not the raw page scope. It is a compatibility projection rather than a security membrane.
 - Context and script name are passed as **unnamed `arguments`** (`arguments[0]`, `arguments[1]`) so user code
   can't shadow them by declaring variables of the same name.
-- `.call(this)` preserves `this` because `chrome.userScripts` invokes the function free-standing (an arrow
-  function would capture the wrong `this`).
+- The wrapper installs the body as a temporary method and removes it in the same expression. This preserves the
+  userscript `this` without resolving mutable page `call`, `apply`, or `bind` properties.
 
 ### Path A — Page scripts → `chrome.userScripts`
 
@@ -38,7 +38,14 @@ patterns and registers the compiled payload (the `scripting` bundle) with `chrom
 `MAIN` or `USER_SCRIPT` world as required. At document time the content/inject pair
 ([`script_runtime.ts`](../../src/app/service/content/script_runtime.ts),
 [`exec_script.ts`](../../src/app/service/content/exec_script.ts)) evaluates the compiled function with the GM
-context.
+context. The `USER_SCRIPT` content path obtains its matched scripts directly from the service worker over
+`ExtensionMessage` after a bootstrap-token handoff. The MAIN `inject` path uses a native extension port for GM RPC
+when available; `PageMessage` carries page-visible bootstrap/fallback traffic, MAIN event/value updates, the
+whitelisted `external.Scriptcat` API, and the MAIN GM RPC fallback through the `scripting` bundle. That fallback
+is checked against the current `PageRpcRegistry` execution handle and grant before it is forwarded to the service
+worker. `CustomEventMessage` carries the content bootstrap handoff and synchronous DOM references. Neither
+page-visible bridge establishes an authenticated extension origin, so consumers must validate its payloads before
+acting on them.
 
 ### Path B — Background scripts → Offscreen → Sandbox
 

diff --git a/docs/references/architecture-gm-api.md b/docs/references/architecture-gm-api.md
@@ -7,12 +7,15 @@ across contexts to a privileged handler, then streams the result back. The imple
 
 - **Content side** ([`src/app/service/content/gm_api/`](../../src/app/service/content/gm_api)) — what runs *near*
   the userscript. Synchronous-feeling APIs (`GM_getValue`, `GM_log`) and the client half of async ones
-  (`GM_xmlhttpRequest`, `GM_setValue`). Built on `GM_Base`, which owns the messaging plumbing.
+  (`GM_xmlhttpRequest`, `GM_setValue`). Built on `GM_Base`, which owns the request facade. `USER_SCRIPT` calls use
+  the native extension channel; the DOM helper remains a narrow synchronous `CustomEventMessage` path.
 - **Service-worker side** ([`src/app/service/service_worker/gm_api/`](../../src/app/service/service_worker/gm_api))
   — the privileged half: permission verification, cross-origin requests, DNR rule building.
 - **Offscreen side** ([`src/app/service/offscreen/gm_api.ts`](../../src/app/service/offscreen/gm_api.ts)) —
   DOM-dependent operations for background scripts (page-context XHR, `window.open`, clipboard).
-- **Values** flow through `ValueService` and are broadcast so every tab running the same script sees updates.
+- **Values** flow through `ValueService`. MAIN updates use the scripting broadcast, while USER_SCRIPT updates are
+  delivered over the native per-document callback port so privileged packets do not cross the page-observable DOM
+  channel.
 
 ### Registration: the `@GMContext.API` decorator
 
@@ -82,4 +85,6 @@ traditional GM API: `@GMContext.API` on the content side
 [`compat-grant.js`](../../packages/eslint/compat-grant.js). What differs is the naming and transport
 shape — the grant is dotted (`CAT.agent.conversation`) and bound with `follow:` rather than `alias:`, the SW
 handlers set `dotAlias: false`, and conversation chat streams over `connect()` instead of `sendMessage`. Copy
-the nearest existing `CAT.agent.*` method rather than a `GM_*` one.
+the nearest existing `CAT.agent.*` method rather than a `GM_*` one. The service-worker handlers derive the script
+identity from `request.script.uuid`, then the Agent services enforce persisted resource ownership; see
+[`architecture-agent.md`](./architecture-agent.md#userscript-resource-ownership) for the scope and legacy rules.
diff --git a/packages/message/README.md b/packages/message/README.md
@@ -19,3 +19,6 @@ document），细节见
 - service_worker 和 offscreen 之间可以使用 postMessage 的方式进行通信，避免同时监听 message 与 connect 导致冲突的问题。
 - service_worker 会在空闲后进入不活动状态；与它建立的 `connect()` 长连接会在此时中断，因此需要长连接的场景要考虑
   重连/状态恢复，而不是假定连接一直存活——这不是禁止在 service_worker 上使用 `connect`，只是需要为其生命周期设计容错。
+- USER_SCRIPT content 和 MAIN inject 优先使用 `ExtensionMessage` 原生扩展通道；服务端区分浏览器提供的 USER_SCRIPT 来源，并把 MAIN 或专用监听器不可用时的普通端口绑定到文档 bootstrap token。
+- `Server("serviceWorker")` 对浏览器标记的 `userScript` 来源仅允许 `connect()` 使用 `runtime/registerUserScript` 或 `runtime/gmApi`，仅允许 `sendMessage()` 使用 `runtime/gmApi` 或 `runtime/reconnectUserScript`；普通 extension 端口不带该来源标记，USER_SCRIPT / MAIN 的注册回退路径会在 `runtime/registerUserScript` 握手中校验文档 bootstrap token。
+- `CustomEventMessage` 和 `PageMessage` 是页面可见的桥：前者承载 content bootstrap 交接与同步 DOM 节点引用，后者承载 MAIN bootstrap/fallback、事件/值更新、白名单 `external.Scriptcat` API，以及经 `scripting` 中转的 GM RPC fallback。它们不提供已认证的扩展来源；`PageMessage` 的 GM RPC 在转发前必须通过 `PageRpcRegistry` 的执行句柄与 grant 校验。
diff --git a/packages/message/common.ts b/packages/message/common.ts
@@ -8,9 +8,14 @@ export const CustomEventClone = CustomEvent;
 const performanceClone = (process.env.VI_TESTING === "true" ? new EventTarget() : performance) as Performance;
 
 // 避免页面载入后改动 EventTarget.prototype 的方法导致消息传递失败
-export const pageDispatchEvent = performanceClone.dispatchEvent.bind(performanceClone);
-export const pageAddEventListener = performanceClone.addEventListener.bind(performanceClone);
-export const pageRemoveEventListener = performanceClone.removeEventListener.bind(performanceClone);
+const nativeReflectApply = Reflect.apply;
+const nativeFunctionBind = Function.prototype.bind;
+const bindNative = <T extends (...args: any[]) => any>(fn: T, receiver: any): T =>
+  nativeReflectApply(nativeFunctionBind, fn, [receiver]) as T;
+
+export const pageDispatchEvent = bindNative(performanceClone.dispatchEvent, performanceClone);
+export const pageAddEventListener = bindNative(performanceClone.addEventListener, performanceClone);
+export const pageRemoveEventListener = bindNative(performanceClone.removeEventListener, performanceClone);
 const detailClone = typeof cloneInto === "function" ? cloneInto : null;
 export const pageDispatchCustomEvent = <T = any>(eventType: string, detail: T) => {
   if (detailClone && detail) detail = <T>detailClone(detail, performanceClone);

diff --git a/packages/message/custom_event_message.test.ts b/packages/message/custom_event_message.test.ts
@@ -1,4 +1,4 @@
-import { describe, expect, it } from "vitest";
+import { describe, expect, it, vi } from "vitest";
 import { CustomEventMessage } from "./custom_event_message";
 import { createMouseEvent, pageDispatchEvent } from "@Packages/message/common";
 
@@ -17,6 +17,30 @@ function createMessagePair() {
 }
 
 describe("CustomEventMessage relatedTarget lifecycle", () => {
+  it("ignores accessor envelopes without executing their getters", () => {
+    const receiver = new CustomEventMessage(`custom-event-message-test-${++flagCounter}`, true, "");
+    const received = vi.fn();
+    receiver.onMessage(received);
+    const envelope: Record<string, unknown> = {
+      messageId: "hostile",
+      type: "sendMessage",
+      data: { action: "custom-event-message-test/hostile" },
+    };
+    let accessed = false;
+    Object.defineProperty(envelope, "data", {
+      configurable: true,
+      enumerable: true,
+      get() {
+        accessed = true;
+        throw new Error("page getter executed");
+      },
+    });
+
+    expect(() => receiver.messageHandle(envelope as any, { postMessage: vi.fn() })).not.toThrow();
+    expect(accessed).toBe(false);
+    expect(received).not.toHaveBeenCalled();
+  });
+
   it("stores a received target on the receiving message until it is consumed", () => {
     const { sender, receiver } = createMessagePair();
     const target = document.createElement("div");