machine-bridge-mcp 3.0.0-beta.205 → 3.0.0-beta.206

package/CHANGELOG.md

@@ -1,21 +1,26 @@
 # Changelog
 
-## 3.0.0-beta.205 - 2026-10-19
-
-- Supersede beta.203 after its Windows atomic-replacement and macOS resource CLI checks failed, and beta.204 after review reproduced an external-generation overwrite during a replacement retry. Repeat exact-package activation and deployed OAuth acceptance for the new candidate.
-- Revalidate the expected content digest before every atomic-replacement attempt so an external edit after a transient sharing failure returns a conflict and retains the external generation; regression coverage also verifies staging cleanup.
-- Preserve an absent coverage environment variable in uninstrumented CLI test children so an exact-runtime version probe retains its light resource classification; assert the actual CLI environment before submission.
-
-- Keep one bridge Durable Object per deployment. The `x-mbm-workspace` / `?workspace=` shard selector is removed: it had no producer, and an unauthenticated request header could fork OAuth clients, tokens, the daemon registry, and pending calls into a second consistency domain.
-- Add an opt-in `--compat` stdio mode for legacy hosts that refuse to start without `initialize`. It accepts the removed handshake and `notifications/initialized` without creating a session, advertises the server's own protocol version instead of echoing the client's, and fills request metadata only when fields are absent; explicit retired, future, or malformed metadata remains subject to normal rejection. `client-config` no longer injects the flag, and `--help` documents it.
-- Make `browser_screenshot.allow_tab_switch` reachable over MCP: the catalog now declares the option and the service parses it as a strict boolean, so non-disruptive capture can fail on an inactive target instead of activating it.
-- Replace the `MBM_DEBUG`-driven verbose error projection with an explicit per-call option. `MBM_DEBUG` no longer widens tool error output, the stdio server opts in per process with `MBM_VERBOSE_ERRORS=1`, the relay never opts in, and verbose messages and causes share the single sanitized 2000-character ceiling of the public message field.
-- Drop the placeholder Desktop Automation and Power Management abstraction classes; capability reporting is now a plain function over the platform.
-- Align `cloudflare.config.ts`, `wrangler.config.ts`, and `wrangler.jsonc` on the documented deployment topology, and relax `devEngines.packageManager` to `warn` so older npm setups do not hard-fail initialization.
-- Bound stdio response backlog and output-buffer copying; harden protected-path resolution, terminal-job evidence checks, file-transaction cleanup reporting, and default instruction-context payloads. Add regression tests for the associated security, settlement, and performance boundaries.
-- Retry bounded transient filesystem sharing errors during atomic file replacement so concurrent Windows readers do not cause a premature update failure; preserve the original error after exhaustion and reject non-transient failures immediately.
-- Repository hygiene: ignore the generated `.workflow/` directory and drop cached review artifacts and intermediate backups from the local workspace.
+## 3.0.0-beta.206 - 2026-10-20
 
+- Fix minute-boundary calculation in progress reporter elapsed formatting to prevent overflow past 60 seconds.
+- Wire progressToken through Worker MCP HTTP contract handling and streamed response dispatch.
+- Remove redundant duplicate self-comparison import in records test suite.
+- Enforce `package.json`/`package-lock.json` root version parity in the version-sync gate and package test.
+- Run progress reporter unit tests against the shared production module, retaining only a local compatibility re-export.
+- Remove the legacy stdio handshake and metadata-normalization mode, including the CLI option and environment switch.
+- Document that multi-file patch rollback covers ordinary operation failures but is not crash-atomic across files; single-file write/edit visibility remains atomic.
+- Add a child-process regression that reproduces the multi-file patch crash window and verifies retained backup/staging artifacts.
+- Expand recursive-search control-plane filtering tests to cover security, browser-pairing, and service-control roots, and test stdio EOF cancellation and output-write failure.
+- Add regression coverage for bounded stdio error responses and serialized concurrent task-state updates.
+- Expand stdio output queue limit and reservation to safely process concurrent maximum-size tool results without dropping the transport.
+- Implement remote Worker MCP Tasks operations (`tasks/get`, `tasks/update`, `tasks/cancel`) for clients that advertise the Tasks extension; local stdio intentionally does not advertise it, `tasks/list`/`tasks/result` aliases are unsupported, project cleanup/interrupted recovery states as active tasks, and tasks without a persisted terminal result fail explicitly if their backing job record disappears before result capture.
+- Centralize MCP task job-ID validation in the shared task contract so task creation, dispatch and durable-record validation use one pattern.
+- Add actionable error guidance (actionable_remedy) for agent reflexion on tool execution failures.
+- Expand local TypeScript type checking coverage to 74 checked modules with strict JSDoc typing.
+- Consolidate cross-module integer validation helpers into shared runtime modules.
+- Add standard npm test script mapped to the verification runner.
+- Tighten TypeScript compiler checks with noFallthroughCasesInSwitch, noImplicitReturns, and noUncheckedIndexedAccess.
+- Include previously orphaned tests into the check runner plan.
 
 ## Historical releases
 

package/README.md

@@ -50,7 +50,7 @@ The complete component and trust-boundary diagram is in [docs/OVERVIEW.md](docs/
 
 ## MCP protocol model
 
-Machine Bridge uses MCP `2026-07-28` for both stdio and remote HTTP under one current request-scoped protocol contract. The default stdio path and remote HTTP require current request-scoped metadata. The opt-in stdio `--compat` shim answers only the legacy initialization handshake and fills metadata fields only when absent; explicit retired, future, or malformed versions remain rejected. It does not restore sessions or replay behavior.
+Machine Bridge uses MCP `2026-07-28` for both stdio and remote HTTP under one request-scoped protocol contract. Both transports require current request-scoped metadata and reject the removed initialization/session/replay behavior. Stdio has no compatibility shim, and neither a CLI flag nor an environment variable can fill missing request metadata.
 Removed protocol requests fail closed with bounded upgrade guidance; hosted clients must reconnect with MCP `2026-07-28` and use `server/discover` rather than initialization.
 - **HTTP streams are request-scoped and non-resumable.** Closing the response stream cancels that request. There is no recovery GET, SSE event-ID replay, or session-bound delivery store.
 - **Removed session/replay semantics never execute.** Unsupported protocol dates and requests for the retired session/recovery model receive bounded rejection or upgrade guidance rather than legacy state or replay behavior.

package/browser-extension/manifest.json

@@ -29,6 +29,6 @@
   "action": {
     "default_title": "Machine Bridge Browser"
   },
-  "version_name": "3.0.0-beta.205",
+  "version_name": "3.0.0-beta.206",
   "key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxryYkpZhq8+VAQLHcGS9BAHQcyKX8RHGIpIwvtIVRU/rcOcE0bNdnM0aZJ/h6xWQsGDHlhvjT2+1aJaAn/9k8473BRWajzVXld961CdHYVFVHoce2hHiSJ0xydWrHMMZhAm0mN0UzjEpgZ0tMw209efcZHIvSwuxhteZMRy4kyiVjwFlOf5oXFCxRuCJnPj3AK9CmCf4XgEBuPIJ0TZmjGHOOdBvJmbCNnAWXYEo5/mf7MfCGhV4IJ1hNuhpoNQfOFKMUcw9/v/IpT62XpfXdGYTfGYCmCjC+gntK1spbkr2P4/2+sYMQtLpse71mpSNGXfcf3abU55Vpn+gncSxRQIDAQAB"
 }

package/docs/AUDIT.md

@@ -21,7 +21,7 @@ This review is scoped to source contracts, risk-bearing control paths, isolated
 - **Workspace replacement retries remain bounded and atomic.** Transient sharing errors retry the staging-file rename without unlinking the visible destination. The expected content digest is rechecked before each attempt, so an external change after a sharing failure returns a conflict and preserves that generation. Exhausted and non-transient failures preserve the original error. Injected success/exhaustion/non-transient and retry-generation regressions supplement the concurrent-reader fixture; Windows CI remains the provider-level proof. This optimistic check does not provide an operating-system compare-and-swap against uncoordinated external writers.
 
 - **Authority remains an intersection, never an accumulation.** Effective MCP authority is bounded by authenticated account role, daemon capability ceiling, and tool-specific policy. Reconnects, retries, stale host schemas, browser focus changes, or recovery metadata do not expand authority.
-- **Removed protocol behavior stays removed.** Remote HTTP and normal stdio use the current MCP protocol only. The sole exception is the opt-in stdio `--compat` handshake: it answers the removed `initialize`/`notifications/initialized` exchange with the supported version and creates no session or replay state. It supplies request metadata only when fields are absent; explicit retired/future versions and malformed metadata remain rejected, and the shim is never reachable from the remote relay.
+- **Removed protocol behavior stays removed.** Remote HTTP and stdio use the current MCP protocol only. `initialize` is rejected, `notifications/initialized` has no handshake effect, and neither a CLI option nor an environment variable can normalize missing request metadata. Clients must supply the current protocol version and capability metadata on every supported request.
 - **State publication is atomic, type-exact and identity-sensitive.** Security-sensitive state readers reject symlinks, unexpected hard links, malformed content, permission failures, persistent identity changes, and coercible PID/token/timestamp fields. Persisted strings, arrays, booleans or objects cannot become process, cleanup, lock, lease, waiter or termination authority through JavaScript conversion. Bounded retries are reserved for explicitly classified atomic-publication races; durable state is complete before it becomes visible.
 - **Durable execution owns continuity explicitly.** Managed jobs persist recovery state independently of the hosted MCP response. Idempotency keys bind uncertain acceptance retries only while the retained record exists; cancellation, dependency state, cleanup, output budgets, and terminal persistence have explicit fail-closed boundaries. Terminal evidence validation is bound to stable status/result file generations, and a live runner retains ownership of its final cleanup-status write. Routine inventory throttles full retention scans to 30 seconds, while capacity pressure, unreadable state, expired staged plans, and dependency-bearing active/staged jobs force maintenance. Callers recover the same accepted job instead of replaying its side effect.
 - **Daemon-owned Node children use a verified runtime launcher.** A live concrete runtime executable is preferred; if it disappears after a package-manager upgrade, only the original absolute Node launcher is eligible as fallback. Diagnostics expose provenance booleans rather than executable paths, and an unavailable launcher requires service restart instead of PATH guessing.

package/docs/CLIENTS.md

@@ -2,23 +2,28 @@
 
 ## The central distinction
 
-An MCP server is not a model provider. It exposes tools, resources, or prompts. The MCP host is the AI application that owns the conversation, chooses or supplies the model, decides when a tool should be called, sends the tool request, and adds the result back to the model context.
+An MCP server is not a model provider.
+It exposes tools, resources, or prompts.
+The MCP host is the AI application that owns the conversation, chooses or supplies the model, decides when a tool should be called, sends the tool request, and adds the result back to the model context.
 
 For this project:
 
 
-A local stdio connection does **not** use the model running in a separate ChatGPT web conversation. It uses whatever model/session the local host is configured to use:
+A local stdio connection does **not** use the model running in a separate ChatGPT web conversation.
+It uses whatever model/session the local host is configured to use:
 
 - Claude Desktop uses the Claude account/model available to that application.
 - Cursor uses the model/provider configured in Cursor.
 - Codex CLI and the Codex IDE integration use their own authenticated Codex/OpenAI configuration.
 - ChatGPT Desktop can use its signed-in ChatGPT/Codex host session and can launch local stdio servers on supported hosts.
 
-The MCP protocol itself intentionally does not dictate how the host obtains an LLM. The optional MCP sampling primitive can let a server ask a capable host for a completion, but `machine-bridge-mcp` does not depend on sampling and does not bundle a model SDK.
+The MCP protocol itself intentionally does not dictate how the host obtains an LLM.
+The optional MCP sampling primitive can let a server ask a capable host for a completion, but `machine-bridge-mcp` does not depend on sampling and does not bundle a model SDK.
 
 ## Why keep stdio when coding clients already have tools?
 
-For many users, the client's native filesystem, patch, terminal, and approval system is sufficient. In that case, adding Machine Bridge over stdio is redundant and should be skipped.
+For many users, the client's native filesystem, patch, terminal, and approval system is sufficient.
+In that case, adding Machine Bridge over stdio is redundant and should be skipped.
 
 The stdio mode exists for narrower cases:
 
@@ -41,19 +46,35 @@ It is therefore an optional compatibility and reuse surface, not a replacement f
 | Several local clients should share identical tool semantics | stdio |
 | Access is required from another device or hosted agent | Remote Worker |
 
-The MCP specification defines stdio and Streamable HTTP as standard transports. In stdio, the host launches the server as a subprocess and exchanges newline-delimited JSON-RPC through stdin/stdout. Streamable HTTP runs the server independently behind an HTTP endpoint.
+The MCP specification defines stdio and Streamable HTTP as standard transports.
+In stdio, the host launches the server as a subprocess and exchanges newline-delimited JSON-RPC through stdin/stdout.
+Streamable HTTP runs the server independently behind an HTTP endpoint.
 
-Machine Bridge uses MCP `2026-07-28` for both stdio and remote Streamable HTTP. Requests carry version and capabilities in `_meta`; `server/discover` replaces initialization, there is no MCP protocol session, and an HTTP response stream belongs to exactly one request. Under default protocol handling, `initialize`, `Mcp-Session-Id`, `Last-Event-ID`, replay markers, and other explicit removed protocol-session markers receive bounded upgrade guidance and cannot dispatch tool work; the opt-in stdio `--compat` shim is the only exception for the initialization handshake. Remote `/mcp` is POST-only, so GET returns 405 rather than acting as a recovery channel. Closing a current request stream cancels that request, and a connection, process, OAuth token, or stdio lifetime is never treated as conversation identity.
+Machine Bridge uses MCP `2026-07-28` for both stdio and remote Streamable HTTP.
+Requests carry version and capabilities in `_meta`; `server/discover` replaces initialization, there is no MCP protocol session, and an HTTP response stream belongs to exactly one request.
+`initialize`, `Mcp-Session-Id`, `Last-Event-ID`, replay markers, and other removed protocol-session markers receive bounded upgrade guidance and cannot dispatch tool work. There is no stdio compatibility shim; clients must use request-scoped metadata and `server/discover`.
+Remote `/mcp` is POST-only, so GET returns 405 rather than acting as a recovery channel.
+Closing a current request stream cancels that request, and a connection, process, OAuth token, or stdio lifetime is never treated as conversation identity.
 
 ## Automatic capability selection
 
-`server/discover` supplies conservative static server guidance, while `session_bootstrap` and `resolve_task_capabilities` explicitly refresh bounded project facts, authority-permitted instructions, skills, explicit/automatic package commands, applications, browser capability, and task-specific execution routes. Use the resolver when that refreshed context or route selection is material; straightforward file, Git, and shell work should use the already exposed tools directly rather than paying an extra discovery round trip. The resolver scores route bundles instead of forcing a single tool: registered commands, Bash/direct argv, process sessions, managed jobs, files/Git, browser, applications, resources, and diagnostics may appear together with ambiguity and fallback metadata. This advice never removes a policy-visible tool; direct Bash remains available under shell-capable authority.
+`server/discover` supplies conservative static server guidance, while `session_bootstrap` and `resolve_task_capabilities` explicitly refresh bounded project facts, authority-permitted instructions, skills, explicit/automatic package commands, applications, browser capability, and task-specific execution routes.
+Use the resolver when that refreshed context or route selection is material; straightforward file, Git, and shell work should use the already exposed tools directly rather than paying an extra discovery round trip.
+The resolver scores route bundles instead of forcing a single tool: registered commands, Bash/direct argv, process sessions, managed jobs, files/Git, browser, applications, resources, and diagnostics may appear together with ambiguity and fallback metadata.
+This advice never removes a policy-visible tool; direct Bash remains available under shell-capable authority.
 
-The resolver always rescans task-specific metadata. A client that already holds `refresh.fingerprint` may send it as `known_refresh_fingerprint`; if the static instruction/skill/command identity is unchanged, the response omits that repeated material but still returns fresh skill/command matches, application results, ranked tools, and route advice. Capability results are filtered by effective account authority, so a restricted role does not receive hidden application/browser/shell metadata from a fuller daemon. No instruction file is required for the default layers, and no repository file is written automatically.
+The resolver always rescans task-specific metadata.
+A client that already holds `refresh.fingerprint` may send it as `known_refresh_fingerprint`; if the static instruction/skill/command identity is unchanged, the response omits that repeated material but still returns fresh skill/command matches, application results, ranked tools, and route advice.
+Capability results are filtered by effective account authority, so a restricted role does not receive hidden application/browser/shell metadata from a fuller daemon.
+No instruction file is required for the default layers, and no repository file is written automatically.
 
-The host still owns the agent loop. A hosted client may use the recommendation automatically, ask for confirmation, expose only part of the catalog, or ignore server instructions. No MCP implementation can guarantee automatic invocation from the server side. Machine Bridge models that limitation explicitly instead of treating a recommendation as execution.
+The host still owns the agent loop.
+A hosted client may use the recommendation automatically, ask for confirmation, expose only part of the catalog, or ignore server instructions.
+No MCP implementation can guarantee automatic invocation from the server side.
+Machine Bridge models that limitation explicitly instead of treating a recommendation as execution.
 
-For browser tasks, the remote host reaches the local extension through the Worker and daemon. The extension controls the existing Chromium profile; it is not a separate Playwright profile.
+For browser tasks, the remote host reaches the local extension through the Worker and daemon.
+The extension controls the existing Chromium profile; it is not a separate Playwright profile.
 
 ## Generate local configuration
 
@@ -75,7 +96,9 @@ machine-mcp client-config --client all --workspace /path/to/project --profile re
 
 ## Current protocol requirements
 
-Use a client that sends the current protocol version and client capabilities in request metadata on every supported request. The default stdio path and remote HTTP reject `initialize` and missing or unsupported request metadata. A narrow, opt-in stdio `--compat` shim answers `initialize`/`notifications/initialized` for hosts that require the handshake and fills metadata fields only when they are absent. It does not support older protocol versions: explicit retired, future, or malformed metadata is still rejected. The environment variable `MBM_MCP_COMPAT=1` enables the same stdio-only shim unless an explicit CLI value overrides it.
+Use a client that sends the current protocol version and client capabilities in request metadata on every supported request.
+The default stdio path and remote HTTP reject `initialize` and missing or unsupported request metadata.
+Stdio has no legacy handshake or metadata-normalization mode. `--compat` is an unsupported option, and `MBM_MCP_COMPAT` is ignored; requests missing the current version or capability metadata are rejected just as they are over remote HTTP.
 
 ## JSON stdio configuration
 
@@ -111,7 +134,8 @@ command = "/absolute/path/to/node"
 args = ["/absolute/path/to/machine-mcp.mjs", "stdio", "--workspace", "/path/to/project", "--profile", "full"]
 ```
 
-Codex CLI, the Codex IDE extension, and supported ChatGPT Desktop Codex hosts can share MCP configuration on the same Codex host. ChatGPT web does not read local Codex configuration files; web use requires a hosted plugin/connector or a reachable remote MCP endpoint.
+Codex CLI, the Codex IDE extension, and supported ChatGPT Desktop Codex hosts can share MCP configuration on the same Codex host.
+ChatGPT web does not read local Codex configuration files; web use requires a hosted plugin/connector or a reachable remote MCP endpoint.
 
 ## Remote hosted-client connection
 
@@ -121,7 +145,9 @@ Run:
 machine-mcp --workspace /path/to/project
 ```
 
-Enter the printed `/mcp` URL in the remote MCP connector. During OAuth authorization, verify the displayed client name and redirect URI before entering a Machine Bridge account name and password. The Worker exposes Streamable HTTP plus protected-resource discovery, authorization-server discovery, dynamic client registration, PKCE S256, `offline_access`, and rotating refresh tokens.
+Enter the printed `/mcp` URL in the remote MCP connector.
+During OAuth authorization, verify the displayed client name and redirect URI before entering a Machine Bridge account name and password.
+The Worker exposes Streamable HTTP plus protected-resource discovery, authorization-server discovery, dynamic client registration, PKCE S256, `offline_access`, and rotating refresh tokens.
 
 Supported configuration paths are:
 
@@ -129,9 +155,15 @@ Supported configuration paths are:
 - **Claude custom connectors:** add the exact `/mcp` URL under Claude's connector settings and leave static OAuth client credentials empty so Claude can use DCR. Hosted Claude surfaces use `https://claude.ai/api/mcp/auth_callback`; the Worker accepts that exact registered redirect and rotates refresh tokens for the public client. See Anthropic's [remote custom connector guide](https://support.claude.com/en/articles/11175166-get-started-with-custom-connectors-using-remote-mcp) and [authentication contract](https://claude.com/docs/connectors/building/authentication).
 - **Microsoft Copilot Studio:** from the agent's **Tools** page, select **Add a tool > New tool > Model Context Protocol**, enter the `/mcp` URL, then select **OAuth 2.0 > Dynamic discovery**. Create the connection and add it to the agent. See Microsoft's [existing MCP server guide](https://learn.microsoft.com/en-us/microsoft-copilot-studio/mcp-add-existing-server-to-agent).
 
-OAuth navigations and form submissions from opaque or client-specific browser containers are routed normally but receive no cross-origin response-sharing permission unless their exact origin is allowed. The authorization page permits form navigation only to itself and the validated redirect origin. For a validated Microsoft `consent.azure-apim.net` callback, the form policy also permits HTTPS subdomains of that same Microsoft consent domain and the exact Copilot Studio origin because Power Platform redirects its global callback to a regional endpoint and then back to Copilot Studio. Claude remote connectors originate from Anthropic infrastructure, while Copilot Studio connectivity runs through Power Platform connectors, so neither is a reason to broaden the browser CORS allowlist.
+OAuth navigations and form submissions from opaque or client-specific browser containers are routed normally but receive no cross-origin response-sharing permission unless their exact origin is allowed.
+The authorization page permits form navigation only to itself and the validated redirect origin.
+For a validated Microsoft `consent.azure-apim.net` callback, the form policy also permits HTTPS subdomains of that same Microsoft consent domain and the exact Copilot Studio origin because Power Platform redirects its global callback to a regional endpoint and then back to Copilot Studio.
+Claude remote connectors originate from Anthropic infrastructure, while Copilot Studio connectivity runs through Power Platform connectors, so neither is a reason to broaden the browser CORS allowlist.
 
-Several OAuth clients and named accounts can coexist. Accounts have independent passwords, roles, active state, versions, authorization codes, access tokens, refresh tokens, and targeted revocation. Their effective tool sets are intersected with the connected daemon policy. All accounts still share one daemon and OS user, so hard tenant isolation requires separate deployments; see [MULTI_ACCOUNT.md](MULTI_ACCOUNT.md).
+Several OAuth clients and named accounts can coexist.
+Accounts have independent passwords, roles, active state, versions, authorization codes, access tokens, refresh tokens, and targeted revocation.
+Their effective tool sets are intersected with the connected daemon policy.
+All accounts still share one daemon and OS user, so hard tenant isolation requires separate deployments; see [MULTI_ACCOUNT.md](MULTI_ACCOUNT.md).
 
 ## Profile guidance
 
@@ -148,31 +180,100 @@ Before connecting a host, verify the local implementation directly:
 machine-mcp full-test --workspace /path/to/project
 ```
 
-A passing result proves that Machine Bridge and the local OS allowed its temporary file/process/shell/key/job probes at that time. It does not prove that a hosted MCP connector will expose every relay-advertised tool, deliver a later request, or that a cloud/remote account will authorize it.
+A passing result proves that Machine Bridge and the local OS allowed its temporary file/process/shell/key/job probes at that time.
+It does not prove that a hosted MCP connector will expose every relay-advertised tool, deliver a later request, or that a cloud/remote account will authorize it.
 
-For SSH automation, prefer `generate_ssh_key_resource` under canonical full, or `machine-mcp resource generate-ssh-key` from the terminal. The private key remains a local resource; private bytes and local paths are omitted by default, while metadata and the bare public fingerprint are returned. Paths require an explicit disclosure option. Installation of the public key into Google OS Login or a remote `authorized_keys` file remains an explicit external action.
+For SSH automation, prefer `generate_ssh_key_resource` under canonical full, or `machine-mcp resource generate-ssh-key` from the terminal.
+The private key remains a local resource; private bytes and local paths are omitted by default, while metadata and the bare public fingerprint are returned.
+Paths require an explicit disclosure option.
+Installation of the public key into Google OS Login or a remote `authorized_keys` file remains an explicit external action.
 
 ## Host-side safety rules
 
-The local `full` profile controls Machine Bridge's own tool catalog, path resolver, path display, process environment, and shell availability. For remote transport, the local transaction gate additionally controls when high-impact effects may run. It does not control the MCP host's model policy, approval UI, connector gateway, or platform execution filters. See [LOCAL_AUTHORIZATION.md](LOCAL_AUTHORIZATION.md).
-
-Host-rendered tool invocation chips, status lines, or labels such as “called tool” are presentation owned by the MCP host, not Machine Bridge log records. Machine Bridge can suppress its own routine per-tool logs outside debug and can reduce unnecessary calls, but it cannot hide or restyle host-owned tool indicators. A host-side UI setting, if one exists, is the only layer that can change that presentation. Prefer fewer, coarser calls and avoid unnecessary capability-resolution calls when direct tools already suffice.
-
-Hosts may cache MCP discovery metadata, input schemas, conversation/surface routing, and workspace-approved app actions independently of the running server. For routine health checks, call `server_info` with `detail: "summary"`; it keeps the effective policy/count, account role without account ID, daemon readiness/relay state, pending/socket capacity, and foreground/settlement limits while omitting OAuth metadata, exact tool arrays, and full observability. The empty/default call returns the current `full` projection and is the cold path when an exact effective-tool list, account identity, or detailed counters are required. `server_info.tool_delivery` reports the current remote foreground maximum, process one-shot maximum, ordinary daemon-tool ceiling, process blocking-poll wait/cooldown ceilings, and Worker settlement overhead. If an already-open host appears to advertise older/larger values, compare the live `server_info` contract with a harmless invocation-validator/behavior probe and, when the deployment uses a frozen ChatGPT workspace app snapshot, the Workspace **Action control** view after the supported refresh/review path. Product-level remediation is warranted only when the governed Workspace approved snapshot itself remains stale/partial/mixed or separate workspace policy requires review. Opaque host-internal cache inspection is intentionally excluded from release and upgrade verification. Product-control-plane actions follow the repository's [authorization contract](https://github.com/YuLeiFuYun/machine-bridge-mcp/blob/main/AGENTS.md#sole-explicit-user-authorization-boundary). The Worker handles known maximum-only version skew as a structured no-side-effect tool error.
-
-For routine workspace inventory, prefer `project_overview` with `detail: "summary"`. It keeps workspace/Git identity, effective and daemon policy/tool counts, compact capability-routing status, and up to 40 top-level names/types, while omitting account ID, exact tool arrays, routing fingerprints, and repeated entry paths/sizes. Request full detail only when those exact diagnostic fields are needed. As with `server_info`, summary is a presentation projection after authorization, not a lower-authority mode. `server_info(detail="summary")` likewise keeps the established hot-path delivery/readiness fields but does not grow with every new exact timing diagnostic; the exact hosted nonterminal progress-coalescing interval is available in full detail while the tool contract and documentation carry the behavioral guarantee.
-
-
-Machine Bridge itself does not block files because their names look sensitive. In remote mode, use the compact projection to inspect `server_info.authorization.effective_policy`; request full detail when exact `effective_tools` membership is required. `daemon.policy` is only the local ceiling. If the effective profile is `full` and the effective tool is present but a direct call is rejected before a structured result, Machine Bridge has no observation of that rejected request and cannot identify the cause from server-side evidence alone; conversation/surface app-routing state, a stale host action/tool snapshot, host tool filtering, connector-gateway policy, client routing, and platform policy are possibilities, not a diagnosis. Conversely, a successful `diagnose_runtime` response proves that request reached the local daemon through the currently used connector path and therefore does not support a blanket claim that Machine Bridge is currently disabled by the platform. A successful same-tool invocation in a fresh supported conversation is additional host-side evidence against a blanket outage when an older conversation still fails before dispatch; treat the difference as a host conversation/surface/snapshot issue until stronger evidence identifies the exact layer. If `diagnose_runtime` arrives but its fixed process or shell probe fails, the likely source moves downstream to local OS policy, endpoint-security software, permissions, shell configuration, or Machine Bridge policy. If an execution tool instead returns a child exit code plus bounded stdout/stderr, the child did start; for nested commands such as `ssh`, a remote forced-command usage screen or allowlist refusal in that output is target-side authorization evidence, not a local spawn or Machine Bridge policy denial. Changing `--profile`, `--unrestricted-paths`, or `--absolute-paths` cannot override host-side, operating-system, or remote-target enforcement.
-
-Expected file-operation failures arrive as ordinary MCP tool-error results, not JSON-RPC transport failures. Clients should branch first on `structuredContent.error.code`, then optionally on the bounded `details.reason`. For example, `conflict/already_exists`, `conflict/hash_mismatch`, `conflict/text_ambiguous`, and `conflict/context_not_found` require a fresh read and reconciliation; `not_found/text_not_found` means the requested edit fragment is absent; `invalid_request` means the request or patch syntax must change. Do not log or display tool arguments to reconstruct diagnostics: public error details intentionally omit paths, file content, edit fragments, and compared hashes.
-
-Remote configurable browser/application foreground tools default to 20 seconds, compound `computer_observe`/`computer_act` default to 30 seconds, and all configurable foreground tools advertise a 45-second maximum. Hosted browser content/action calls require an explicit `tab_id` obtained from `browser_list_tabs`, and hosted `computer_observe(surface="browser")` requires the same explicit target before it issues a snapshot; they do not silently retarget to whichever shared Chromium tab happens to be active. Those values bound daemon execution; the Worker records its settlement deadline five seconds later. Remote `exec_command`, `run_process`, and `run_local_command` use a separate durable 10-second acceptance contract with independently bounded detached execution. Hosted `read_process` supports paced same-response follow-up: the actual output/exit blocking wait is at most one second, while a repeated would-block request inside the fifteen-second cooldown remains inside that same MCP call until output/exit or the cooldown boundary instead of returning a rapid running checkpoint. A live result reports `status_polling_mode=paced_followup` plus `next_blocking_poll_after_ms`; callers may continue reading when the current task needs output or terminal state, but must not busy-loop. Admission and transport latency may consume part of an individual request interval, and none of these values guarantees host receipt. They are not evidence for a guessed whole-assistant-turn deadline: clients must not stop merely because some number of wall-clock minutes has elapsed. Missing or role-hidden tools, non-object arguments, and requests above current limits fail at the shared Worker schema boundary before daemon dispatch; schema failures include `side_effects_started=false`. SSE-capable current requests receive the same pre-dispatch validation as JSON responses and never allocate a recovery stream. Do not treat this as a retry invitation for the same oversized mutation, and do not attempt to evade a host refusal by renaming, encoding, or switching to another arbitrary execution tool. Durable acceptance does not force a hosted-turn handoff. When the current task needs terminal state, a known active job may be followed through bounded same-response `read_job` calls while calls continue to be accepted; relay reads report `status_polling_mode=bounded_followup` and `host_turn_handoff_recommended=false`. Hosted active `read_job` defaults to a 40-second server-side long-poll. Terminal settlement returns on the next bounded five-second internal poll; nonterminal status/phase/dependency progress is coalesced for at least 30 seconds by default, and `current_step`-only churn does not wake the hosted call. `wait_ms=0` requests an immediate checkpoint, while public hosted `wait_ms` is capped at 60 seconds. The default is deliberately 40 seconds rather than equal to that maximum: live acceptance must prove that the target host carries the omitted-parameter default without terminating the tool call, and longer jobs continue through another paced read of the same `job_id` rather than a longer single HTTP request. Per-call survival does not establish aggregate assistant-response lifetime; a host may still impose a real boundary after many individually successful reads. Do not replace server-side pacing with a rapid host-side checkpoint loop. Handoff is justified only after an actual host/tool boundary is observed, external input or authorization is required, or the user explicitly requested a checkpoint. After a real host boundary, resume the same durable `job_id` rather than resubmitting the operation. For a coherent non-interactive workflow with several local commands, prefer a repository umbrella command or one multi-step `start_job` rather than a chain of one-step process carriers; this is a host-event-density control, not a task-duration limit. A valid job ID that is no longer retained returns typed `not_found`; this is missing recovery evidence, not proof that its side effect never executed. Completed one-step process carriers use lower-priority terminal retention than explicit managed jobs, so removable helper history is reclaimed first within the shared 512-state durable store. Hosted `list_jobs` is an aggregate-only inventory surface: the Worker removes job IDs, names, and `recent_process_recovery` handles, while local CLI/stdio retains the detailed bounded inventory for administration. The same pacing principle applies to read-only status/diagnostic surfaces such as `server_info` and `diagnose_runtime`: use them to capture relevant evidence rather than switching surfaces merely to wait on the same background state. `server/discover` and `tools/list` both advertise `ttlMs=0`; discovery instructions therefore refresh alongside the tool contract, every host-visible tool description carries `Tool schema generation N`, and `server_info.tool_delivery` exposes the current generation/version plus `discovery_ttl_ms=0` and `tool_list_ttl_ms=0` while reporting that the server cannot know which generation an external host has cached. `host_turn_deadline_observable=false` means Machine Bridge also cannot predict when the external host will terminate an assistant turn; `managed_jobs_detached_from_mcp_response=true` means that boundary does not itself cancel an already accepted durable job. A release that changes tool semantics therefore verifies the live Machine Bridge runtime/discovery contract and harmless changed-generation invocation behavior after activation. When ChatGPT workspace governance freezes approved actions, use the Workspace Action control snapshot after automation performs the supported refresh/review path as the product-level publication evidence. Opaque host-internal cache inspection is intentionally excluded from release acceptance and must not trigger reconnect, refresh, recreation, or republication. For durable workflows that must survive a later host boundary:
+The local `full` profile controls Machine Bridge's own tool catalog, path resolver, path display, process environment, and shell availability.
+For remote transport, the local transaction gate additionally controls when high-impact effects may run.
+It does not control the MCP host's model policy, approval UI, connector gateway, or platform execution filters.
+See [LOCAL_AUTHORIZATION.md](LOCAL_AUTHORIZATION.md).
+
+Host-rendered tool invocation chips, status lines, or labels such as “called tool” are presentation owned by the MCP host, not Machine Bridge log records.
+Machine Bridge can suppress its own routine per-tool logs outside debug and can reduce unnecessary calls, but it cannot hide or restyle host-owned tool indicators.
+A host-side UI setting, if one exists, is the only layer that can change that presentation.
+Prefer fewer, coarser calls and avoid unnecessary capability-resolution calls when direct tools already suffice.
+
+Hosts may cache MCP discovery metadata, input schemas, conversation/surface routing, and workspace-approved app actions independently of the running server.
+For routine health checks, call `server_info` with `detail: "summary"`; it keeps the effective policy/count, account role without account ID, daemon readiness/relay state, pending/socket capacity, and foreground/settlement limits while omitting OAuth metadata, exact tool arrays, and full observability.
+The empty/default call returns the current `full` projection and is the cold path when an exact effective-tool list, account identity, or detailed counters are required.
+`server_info.tool_delivery` reports the current remote foreground maximum, process one-shot maximum, ordinary daemon-tool ceiling, process blocking-poll wait/cooldown ceilings, and Worker settlement overhead.
+If an already-open host appears to advertise older/larger values, compare the live `server_info` contract with a harmless invocation-validator/behavior probe and, when the deployment uses a frozen ChatGPT workspace app snapshot, the Workspace **Action control** view after the supported refresh/review path.
+Product-level remediation is warranted only when the governed Workspace approved snapshot itself remains stale/partial/mixed or separate workspace policy requires review.
+Opaque host-internal cache inspection is intentionally excluded from release and upgrade verification.
+Product-control-plane actions follow the repository's [authorization contract](https://github.com/YuLeiFuYun/machine-bridge-mcp/blob/main/AGENTS.md#sole-explicit-user-authorization-boundary).
+The Worker handles known maximum-only version skew as a structured no-side-effect tool error.
+
+For routine workspace inventory, prefer `project_overview` with `detail: "summary"`.
+It keeps workspace/Git identity, effective and daemon policy/tool counts, compact capability-routing status, and up to 40 top-level names/types, while omitting account ID, exact tool arrays, routing fingerprints, and repeated entry paths/sizes.
+Request full detail only when those exact diagnostic fields are needed.
+As with `server_info`, summary is a presentation projection after authorization, not a lower-authority mode.
+`server_info(detail="summary")` likewise keeps the established hot-path delivery/readiness fields but does not grow with every new exact timing diagnostic; the exact hosted nonterminal progress-coalescing interval is available in full detail while the tool contract and documentation carry the behavioral guarantee.
+
+
+Machine Bridge itself does not block files because their names look sensitive.
+In remote mode, use the compact projection to inspect `server_info.authorization.effective_policy`; request full detail when exact `effective_tools` membership is required.
+`daemon.policy` is only the local ceiling.
+If the effective profile is `full` and the effective tool is present but a direct call is rejected before a structured result, Machine Bridge has no observation of that rejected request and cannot identify the cause from server-side evidence alone; conversation/surface app-routing state, a stale host action/tool snapshot, host tool filtering, connector-gateway policy, client routing, and platform policy are possibilities, not a diagnosis.
+Conversely, a successful `diagnose_runtime` response proves that request reached the local daemon through the currently used connector path and therefore does not support a blanket claim that Machine Bridge is currently disabled by the platform.
+A successful same-tool invocation in a fresh supported conversation is additional host-side evidence against a blanket outage when an older conversation still fails before dispatch; treat the difference as a host conversation/surface/snapshot issue until stronger evidence identifies the exact layer.
+If `diagnose_runtime` arrives but its fixed process or shell probe fails, the likely source moves downstream to local OS policy, endpoint-security software, permissions, shell configuration, or Machine Bridge policy.
+If an execution tool instead returns a child exit code plus bounded stdout/stderr, the child did start; for nested commands such as `ssh`, a remote forced-command usage screen or allowlist refusal in that output is target-side authorization evidence, not a local spawn or Machine Bridge policy denial.
+Changing `--profile`, `--unrestricted-paths`, or `--absolute-paths` cannot override host-side, operating-system, or remote-target enforcement.
+
+Expected file-operation failures arrive as ordinary MCP tool-error results, not JSON-RPC transport failures.
+Clients should branch first on `structuredContent.error.code`, then optionally on the bounded `details.reason`.
+For example, `conflict/already_exists`, `conflict/hash_mismatch`, `conflict/text_ambiguous`, and `conflict/context_not_found` require a fresh read and reconciliation; `not_found/text_not_found` means the requested edit fragment is absent; `invalid_request` means the request or patch syntax must change.
+Do not log or display tool arguments to reconstruct diagnostics: public error details intentionally omit paths, file content, edit fragments, and compared hashes.
+
+Remote configurable browser/application foreground tools default to 20 seconds, compound `computer_observe`/`computer_act` default to 30 seconds, and all configurable foreground tools advertise a 45-second maximum.
+Hosted browser content/action calls require an explicit `tab_id` obtained from `browser_list_tabs`, and hosted `computer_observe(surface="browser")` requires the same explicit target before it issues a snapshot; they do not silently retarget to whichever shared Chromium tab happens to be active.
+Those values bound daemon execution; the Worker records its settlement deadline five seconds later.
+Remote `exec_command`, `run_process`, and `run_local_command` use a separate durable 10-second acceptance contract with independently bounded detached execution.
+Hosted `read_process` supports paced same-response follow-up: the actual output/exit blocking wait is at most one second, while a repeated would-block request inside the fifteen-second cooldown remains inside that same MCP call until output/exit or the cooldown boundary instead of returning a rapid running checkpoint.
+A live result reports `status_polling_mode=paced_followup` plus `next_blocking_poll_after_ms`; callers may continue reading when the current task needs output or terminal state, but must not busy-loop.
+Admission and transport latency may consume part of an individual request interval, and none of these values guarantees host receipt.
+They are not evidence for a guessed whole-assistant-turn deadline: clients must not stop merely because some number of wall-clock minutes has elapsed.
+Missing or role-hidden tools, non-object arguments, and requests above current limits fail at the shared Worker schema boundary before daemon dispatch; schema failures include `side_effects_started=false`.
+SSE-capable current requests receive the same pre-dispatch validation as JSON responses and never allocate a recovery stream.
+Do not treat this as a retry invitation for the same oversized mutation, and do not attempt to evade a host refusal by renaming, encoding, or switching to another arbitrary execution tool.
+Durable acceptance does not force a hosted-turn handoff.
+When the current task needs terminal state, a known active job may be followed through bounded same-response `read_job` calls while calls continue to be accepted; relay reads report `status_polling_mode=bounded_followup` and `host_turn_handoff_recommended=false`.
+Hosted active `read_job` defaults to a 40-second server-side long-poll.
+Terminal settlement returns on the next bounded five-second internal poll; nonterminal status/phase/dependency progress is coalesced for at least 30 seconds by default, and `current_step`-only churn does not wake the hosted call.
+`wait_ms=0` requests an immediate checkpoint, while public hosted `wait_ms` is capped at 60 seconds.
+The default is deliberately 40 seconds rather than equal to that maximum: live acceptance must prove that the target host carries the omitted-parameter default without terminating the tool call, and longer jobs continue through another paced read of the same `job_id` rather than a longer single HTTP request.
+Per-call survival does not establish aggregate assistant-response lifetime; a host may still impose a real boundary after many individually successful reads.
+Do not replace server-side pacing with a rapid host-side checkpoint loop.
+Handoff is justified only after an actual host/tool boundary is observed, external input or authorization is required, or the user explicitly requested a checkpoint.
+After a real host boundary, resume the same durable `job_id` rather than resubmitting the operation.
+For a coherent non-interactive workflow with several local commands, prefer a repository umbrella command or one multi-step `start_job` rather than a chain of one-step process carriers; this is a host-event-density control, not a task-duration limit.
+A valid job ID that is no longer retained returns typed `not_found`; this is missing recovery evidence, not proof that its side effect never executed.
+Completed one-step process carriers use lower-priority terminal retention than explicit managed jobs, so removable helper history is reclaimed first within the shared 512-state durable store.
+Hosted `list_jobs` is an aggregate-only inventory surface: the Worker removes job IDs, names, and `recent_process_recovery` handles, while local CLI/stdio retains the detailed bounded inventory for administration.
+The same pacing principle applies to read-only status/diagnostic surfaces such as `server_info` and `diagnose_runtime`: use them to capture relevant evidence rather than switching surfaces merely to wait on the same background state.
+`server/discover` and `tools/list` both advertise `ttlMs=0`; discovery instructions therefore refresh alongside the tool contract, every host-visible tool description carries `Tool schema generation N`, and `server_info.tool_delivery` exposes the current generation/version plus `discovery_ttl_ms=0` and `tool_list_ttl_ms=0` while reporting that the server cannot know which generation an external host has cached.
+`host_turn_deadline_observable=false` means Machine Bridge also cannot predict when the external host will terminate an assistant turn; `managed_jobs_detached_from_mcp_response=true` means that boundary does not itself cancel an already accepted durable job.
+A release that changes tool semantics therefore verifies the live Machine Bridge runtime/discovery contract and harmless changed-generation invocation behavior after activation.
+When ChatGPT workspace governance freezes approved actions, use the Workspace Action control snapshot after automation performs the supported refresh/review path as the product-level publication evidence.
+Opaque host-internal cache inspection is intentionally excluded from release acceptance and must not trigger reconnect, refresh, recreation, or republication.
+For durable workflows that must survive a later host boundary:
 
 1. register credentials locally as resource aliases so their values never enter MCP arguments;
-2. choose a fresh `idempotency_key` and submit a complete policy-authorized `start_job` plan before the workflow depends on later cleanup calls; hosted `start_job` requires that key before dispatch so an ambiguous acceptance response can be retried with the same logical arguments instead of creating a second job. Preserve the returned `job_id`, `recovery_key`, and `control_key` together: hosted `read_job` requires `recovery_key`, `cancel_job` requires `control_key`, and `depends_on` requires an exact `dependency_recovery` mapping. These capabilities are purpose/principal bound and are not discoverable through hosted `list_jobs`; batch coherent non-interactive local commands into that managed plan (or a repository umbrella command) instead of creating a one-step tool event for every small probe; `stage_job` is only a non-running draft, while an explicit local operator may use `machine-mcp job submit PLAN.json`;
+2. choose a fresh `idempotency_key` and submit a complete policy-authorized `start_job` plan before the workflow depends on later cleanup calls; hosted `start_job` requires that key before dispatch so an ambiguous acceptance response can be retried with the same logical arguments instead of creating a second job.
+Preserve the returned `job_id`, `recovery_key`, and `control_key` together: hosted `read_job` requires `recovery_key`, `cancel_job` requires `control_key`, and `depends_on` requires an exact `dependency_recovery` mapping.
+These capabilities are purpose/principal bound and are not discoverable through hosted `list_jobs`; batch coherent non-interactive local commands into that managed plan (or a repository umbrella command) instead of creating a one-step tool event for every small probe; `stage_job` is only a non-running draft, while an explicit local operator may use `machine-mcp job submit PLAN.json`;
 3. use job-scoped temporary files or remote stdin scripts;
 4. put idempotent cleanup in `finally_steps`;
 5. inspect/cancel through `machine-mcp job ...` if the host later denies tools.
 
-The initial `start_job` request is still subject to host approval. If it is blocked before dispatch, the operator can review and submit the same JSON plan locally with `machine-mcp job submit plan.json`. If the hosted acceptance outcome is **unknown** rather than definitely blocked, do not switch to a second submission path: retry the same hosted arguments with the same `idempotency_key` while the retained recovery window is still valid. See [MANAGED_JOBS.md](MANAGED_JOBS.md).
+The initial `start_job` request is still subject to host approval.
+If it is blocked before dispatch, the operator can review and submit the same JSON plan locally with `machine-mcp job submit plan.json`.
+If the hosted acceptance outcome is **unknown** rather than definitely blocked, do not switch to a second submission path: retry the same hosted arguments with the same `idempotency_key` while the retained recovery window is still valid.
+See [MANAGED_JOBS.md](MANAGED_JOBS.md).