@opengeni/runtime 2.5.2 → 2.5.3-canary.1

package/dist/index.d.ts

@@ -1,4 +1,7 @@
 import type { ModelProviderApi, ResolvedModelProvider, Settings } from "@opengeni/config";
+import { type McpOperationPersistence } from "./mcp-operation-dispatch.js";
+export { captureMcpOperationDispatch, hasActiveRecoverableMcpOperation, McpOperationOutcomeUnknownError, runRecoverableMcpOperation, type CapturedMcpOperation, type McpOperationPersistence, type RecoverableMcpOperation, } from "./mcp-operation-dispatch.js";
+export { assertMcpOperationObservationAuthority, observeMcpOperation, runMcpOperationObservationWithAuthority, type McpOperationObservationAuthority, type McpObservationBinding, type McpObservationReceipt, } from "./mcp-operation-observation.js";
 import { type SkillCatalogDescriptor } from "./skill-catalog.js";
 export { formatSkillCatalog, type SkillCatalogDescriptor } from "./skill-catalog.js";
 import { AttemptToolEnvironment, type AttemptToolAuthorization, type AttemptToolDefinition } from "@opengeni/codemode";
@@ -90,6 +93,8 @@ export type ResolveConnectionCredentialResult = {
     connectionId: string;
     authoritySource?: "host";
     authorizeProviderRequest?: () => Promise<boolean>;
+    /** Metadata-only immutable authority binding supplied by the trusted worker resolver. */
+    operationAuthorityDigest?: string;
     expiresAt?: Date | null;
 } | {
     status: "auth_needed";
@@ -707,6 +712,8 @@ export type ToolPreparationPhaseMeasurement = {
     durationSeconds: number;
 };
 export type PrepareToolsOptions = {
+    /** Opt-in exact-attempt persistence; absence preserves ordinary MCP execution. */
+    mcpOperationPersistence?: McpOperationPersistence;
     /** Live exact-owner control refresh; API remains read/observation authority. */
     refreshOwnedCommand?: (commandId: string) => Promise<boolean>;
     accountId?: string;

package/dist/index.js

@@ -30,6 +30,7 @@ import {
   MCP_LIFECYCLE_POLICIES,
   MCP_TOOL_CALL_OUTCOMES,
   MIN_COMPACTION_THRESHOLD_RATIO,
+  McpOperationOutcomeUnknownError,
   MultiProviderModelProvider,
   OPENGENI_INNER_MCP_CUSTOM_DATA_KEY,
   OPENGENI_MCP_RESULT_CUSTOM_DATA_KEY,
@@ -73,6 +74,7 @@ import {
   appendWorkspaceGovernance,
   appendWorkspaceMemory,
   applyMissingManifestEntries,
+  assertMcpOperationObservationAuthority,
   assertOpenSuffixResumable,
   azureCliLoginCommand,
   azureOpenAIDefaultQuery,
@@ -91,6 +93,7 @@ import {
   buildRemoteV2ReplacementHistory,
   buildSummaryItem,
   callModelInputFilterForSettings,
+  captureMcpOperationDispatch,
   clampCompactionThresholdRatio,
   codemodeTokenSeedCommand,
   compactMcpResultCustomDataRunState,
@@ -137,6 +140,7 @@ import {
   gitCredentialBindingHash,
   gitCredentialBindingTokenRefreshCommand,
   gitProviderTokenRefreshCommand,
+  hasActiveRecoverableMcpOperation,
   hasActiveWorkspaceInstructionPolicy,
   hasCanonicalEditableArtifactToolSurface,
   hasModelGeneratedItem,
@@ -174,6 +178,7 @@ import {
   normalizeSdkEvent,
   normalizeToolOutputForEvent,
   normalizeVercelGatewayRequestBody,
+  observeMcpOperation,
   oneShotGenesisTitleInputFilter,
   opaqueEncryptedContentLength,
   persistentAgentInstructionInspectionFor,
@@ -215,7 +220,9 @@ import {
   runAzureCliLoginHook,
   runBeforeAgentStartHooks,
   runCodemodeTokenSeedHook,
+  runMcpOperationObservationWithAuthority,
   runOwnedSandboxSetup,
+  runRecoverableMcpOperation,
   runRepositoryCloneHook,
   runRigSetupHook,
   runtimeSkillIndexForAgent,
@@ -247,7 +254,7 @@ import {
   workspaceEnvironmentInstructions,
   wrapAttemptToolDefinitions,
   wrapAttemptToolExecute
-} from "./chunk-GJC7H2FC.js";
+} from "./chunk-VUEWS4GI.js";
 import {
   ActiveBackendUnresolvableError,
   BROWSER_CONTROL_ADMIN_TOKEN_FILE,
@@ -361,6 +368,7 @@ import {
   buildTerminalServerScript,
   cancelSelfhostedOp,
   captureVerifiedWorkspaceArchive,
+  captureWorkspaceArchiveForStorage,
   classifyProviderSandboxFailure,
   clearRunCredentials,
   clearRunCredentialsForAttempt,
@@ -385,6 +393,7 @@ import {
   describeNativeSnapshotArchive,
   deserializeSandboxSessionStateEnvelope,
   desktopCapableBackend,
+  disposeWorkspaceArchive,
   dockerNetworkExposedPortEndpoint,
   drainingExhaustedError,
   drainingMessage,
@@ -517,8 +526,8 @@ import {
   withRunCredentialsClient,
   withRunCredentialsSession,
   withoutSandboxProviderIdentity
-} from "./chunk-LGLJ5PVD.js";
-import "./chunk-CD22I76N.js";
+} from "./chunk-46BFUGFL.js";
+import "./chunk-FHGLYLBL.js";
 import {
   SKILL_MAX_FILES,
   SKILL_MAX_FILE_BYTES,
@@ -543,7 +552,7 @@ import {
 } from "./chunk-JHM4OS7C.js";
 import {
   MaxTurnsExceededError
-} from "./chunk-25B3EQRW.js";
+} from "./chunk-UNICCRW5.js";
 import "./chunk-PZ5AY32C.js";
 export {
   ActiveBackendUnresolvableError,
@@ -616,6 +625,7 @@ export {
   MIN_COMPACTION_THRESHOLD_RATIO,
   MODAL_EXEC_READINESS_TIMEOUT_MS,
   MaxTurnsExceededError,
+  McpOperationOutcomeUnknownError,
   MockAgentResponder,
   MultiProviderModelProvider,
   NEVER_SENT_DETAIL_KEY,
@@ -729,6 +739,7 @@ export {
   applyMissingManifestEntries,
   assertConsistentSandboxProviderIdentity,
   assertDescriptorRegistryInvariants,
+  assertMcpOperationObservationAuthority,
   assertOpenSuffixResumable,
   assertProviderRegistryInvariants,
   assertSafeRelPath,
@@ -758,7 +769,9 @@ export {
   buildTerminalServerScript,
   callModelInputFilterForSettings,
   cancelSelfhostedOp,
+  captureMcpOperationDispatch,
   captureVerifiedWorkspaceArchive,
+  captureWorkspaceArchiveForStorage,
   clampCompactionThresholdRatio,
   classifyProviderSandboxFailure,
   clearRunCredentials,
@@ -804,6 +817,7 @@ export {
   describeNativeSnapshotArchive,
   deserializeSandboxSessionStateEnvelope,
   desktopCapableBackend,
+  disposeWorkspaceArchive,
   dockerNetworkExposedPortEndpoint,
   drainingExhaustedError,
   drainingMessage,
@@ -846,6 +860,7 @@ export {
   gitCredentialBindingTokenRefreshCommand,
   gitProviderTokenRefreshCommand,
   gmailRestToolIsMutation,
+  hasActiveRecoverableMcpOperation,
   hasActiveWorkspaceInstructionPolicy,
   hasCanonicalEditableArtifactToolSurface,
   hasModelGeneratedItem,
@@ -916,6 +931,7 @@ export {
   normalizeSdkEvent,
   normalizeToolOutputForEvent,
   normalizeVercelGatewayRequestBody,
+  observeMcpOperation,
   offlineAgentError,
   offlineControlResponse,
   oneShotGenesisTitleInputFilter,
@@ -994,7 +1010,9 @@ export {
   runCodemodeTokenSeedHook,
   runCredentialPointerFile,
   runCredentialRoot,
+  runMcpOperationObservationWithAuthority,
   runOwnedSandboxSetup,
+  runRecoverableMcpOperation,
   runRepositoryCloneHook,
   runRigSetupHook,
   runStateCompatibilityProvider,

package/dist/{localSources-Z5IJIIRV.js → localSources-PVFCAPN2.js}

@@ -3,8 +3,8 @@ import {
   applyLocalSourceManifestToState,
   materializeLocalSourceManifest,
   materializeLocalSourceManifestEntry
-} from "./chunk-CD22I76N.js";
-import "./chunk-25B3EQRW.js";
+} from "./chunk-FHGLYLBL.js";
+import "./chunk-UNICCRW5.js";
 import "./chunk-PZ5AY32C.js";
 export {
   applyLocalSourceManifestEntryToState,
@@ -12,4 +12,4 @@ export {
   materializeLocalSourceManifest,
   materializeLocalSourceManifestEntry
 };
-//# sourceMappingURL=localSources-Z5IJIIRV.js.map
+//# sourceMappingURL=localSources-PVFCAPN2.js.map

package/dist/mcp-operation-dispatch.d.ts

@@ -0,0 +1,45 @@
+import type { AttemptToolResult } from "@opengeni/contracts";
+export type RecoverableMcpOperation = {
+    operationId: string;
+    sourceCallId?: string;
+    serverId: string;
+    originalTool: string;
+    observerTool: string;
+    destinationDigest: string;
+    argumentDigest: string;
+};
+export type CapturedMcpOperation = RecoverableMcpOperation & {
+    authorityDigest: string;
+};
+/** Worker-owned persistence. Its implementation must enforce canonical live
+ * attempt identity and store no arguments, URLs, headers, or credentials. */
+export type McpOperationPersistence = {
+    capture: (operation: CapturedMcpOperation) => Promise<"created" | "existing">;
+    settleOriginal: (input: {
+        operationId: string;
+        outcome: "completed";
+        result: AttemptToolResult;
+    } | {
+        operationId: string;
+        outcome: "outcome_unknown";
+    }) => Promise<void>;
+};
+/** Presence is an execution-routing fact, not authorization. A closed context
+ * remains visible to late callbacks so they still hit the dispatch fence. */
+export declare function hasActiveRecoverableMcpOperation(): boolean;
+export declare class McpOperationOutcomeUnknownError extends Error {
+    readonly operationId: string;
+    readonly code = "mcp_operation_outcome_unknown";
+    constructor(operationId: string, cause: unknown);
+}
+/** Establish trusted in-process correlation around one gateway execution. */
+export declare function runRecoverableMcpOperation(operation: RecoverableMcpOperation, persistence: McpOperationPersistence, execute: () => Promise<AttemptToolResult>): Promise<AttemptToolResult>;
+/** Called by the authorized broker immediately before the physical request.
+ * A second dispatch with the same identity is never an observation. */
+export declare function captureMcpOperationDispatch(input: {
+    operationId: string;
+    serverId: string;
+    toolName: string;
+    destinationDigest: string;
+    authorityDigest: string;
+}): Promise<void>;

package/dist/mcp-operation-observation.d.ts

@@ -0,0 +1,137 @@
+import { z } from "zod";
+export type McpOperationObservationAuthority = {
+    serverId: string;
+    observerTool: string;
+    destinationDigest: string;
+    authorityDigest: string;
+};
+/** Pin the actual broker request, not merely the earlier credential lookup. */
+export declare function runMcpOperationObservationWithAuthority<T>(binding: McpOperationObservationAuthority, execute: () => Promise<T>): Promise<T>;
+/** The caller is the credential broker, after live authorization and before
+ * physical tools/call dispatch. Unrelated ordinary calls remain unchanged. */
+export declare function assertMcpOperationObservationAuthority(actual: {
+    serverId: string;
+    toolName?: string;
+    destinationDigest: string;
+    authorityDigest?: string;
+}): void;
+declare const receiptSchema: z.ZodDiscriminatedUnion<[z.ZodObject<{
+    version: z.ZodLiteral<1>;
+    operationRef: z.ZodString;
+    fingerprint: z.ZodObject<{
+        version: z.ZodLiteral<1>;
+        algorithm: z.ZodLiteral<"sha256">;
+        value: z.ZodString;
+    }, z.core.$strict>;
+    status: z.ZodLiteral<"unknown">;
+}, z.core.$strict>, z.ZodObject<{
+    version: z.ZodLiteral<1>;
+    operationRef: z.ZodString;
+    fingerprint: z.ZodObject<{
+        version: z.ZodLiteral<1>;
+        algorithm: z.ZodLiteral<"sha256">;
+        value: z.ZodString;
+    }, z.core.$strict>;
+    status: z.ZodLiteral<"pending">;
+    evidenceRevision: z.ZodString;
+}, z.core.$strict>, z.ZodObject<{
+    version: z.ZodLiteral<1>;
+    operationRef: z.ZodString;
+    fingerprint: z.ZodObject<{
+        version: z.ZodLiteral<1>;
+        algorithm: z.ZodLiteral<"sha256">;
+        value: z.ZodString;
+    }, z.core.$strict>;
+    status: z.ZodLiteral<"completed">;
+    receiptRevision: z.ZodString;
+    result: z.ZodObject<{
+        content: z.ZodArray<z.ZodDiscriminatedUnion<[z.ZodObject<{
+            type: z.ZodLiteral<"text">;
+            text: z.ZodString;
+            annotations: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodJSONSchema>>;
+            _meta: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodJSONSchema>>;
+        }, z.core.$loose>, z.ZodObject<{
+            type: z.ZodLiteral<"image">;
+            data: z.ZodString;
+            mimeType: z.ZodString;
+            annotations: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodJSONSchema>>;
+            _meta: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodJSONSchema>>;
+        }, z.core.$loose>, z.ZodObject<{
+            type: z.ZodLiteral<"audio">;
+            data: z.ZodString;
+            mimeType: z.ZodString;
+            annotations: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodJSONSchema>>;
+            _meta: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodJSONSchema>>;
+        }, z.core.$loose>, z.ZodObject<{
+            type: z.ZodLiteral<"resource_link">;
+            name: z.ZodString;
+            title: z.ZodOptional<z.ZodString>;
+            uri: z.ZodString;
+            description: z.ZodOptional<z.ZodString>;
+            mimeType: z.ZodOptional<z.ZodString>;
+            size: z.ZodOptional<z.ZodNumber>;
+            icons: z.ZodOptional<z.ZodArray<z.ZodObject<{
+                src: z.ZodString;
+                mimeType: z.ZodOptional<z.ZodString>;
+                sizes: z.ZodOptional<z.ZodArray<z.ZodString>>;
+                theme: z.ZodOptional<z.ZodEnum<{
+                    dark: "dark";
+                    light: "light";
+                }>>;
+            }, z.core.$strict>>>;
+            annotations: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodJSONSchema>>;
+            _meta: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodJSONSchema>>;
+        }, z.core.$loose>, z.ZodObject<{
+            type: z.ZodLiteral<"resource">;
+            resource: z.ZodUnion<readonly [z.ZodObject<{
+                uri: z.ZodString;
+                mimeType: z.ZodOptional<z.ZodString>;
+                text: z.ZodString;
+                _meta: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodJSONSchema>>;
+            }, z.core.$loose>, z.ZodObject<{
+                uri: z.ZodString;
+                mimeType: z.ZodOptional<z.ZodString>;
+                blob: z.ZodString;
+                _meta: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodJSONSchema>>;
+            }, z.core.$loose>]>;
+            annotations: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodJSONSchema>>;
+            _meta: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodJSONSchema>>;
+        }, z.core.$loose>], "type">>;
+        structuredContent: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodJSONSchema>>;
+        isError: z.ZodOptional<z.ZodBoolean>;
+        _meta: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodJSONSchema>>;
+    }, z.core.$loose>;
+}, z.core.$strict>, z.ZodObject<{
+    version: z.ZodLiteral<1>;
+    operationRef: z.ZodString;
+    fingerprint: z.ZodObject<{
+        version: z.ZodLiteral<1>;
+        algorithm: z.ZodLiteral<"sha256">;
+        value: z.ZodString;
+    }, z.core.$strict>;
+    status: z.ZodLiteral<"conflict">;
+}, z.core.$strict>], "status">;
+declare const bindingSchema: z.ZodObject<{
+    operationId: z.ZodString;
+    serverId: z.ZodString;
+    originalTool: z.ZodString;
+    observerTool: z.ZodString;
+    argumentDigest: z.ZodString;
+}, z.core.$strict>;
+export type McpObservationBinding = z.infer<typeof bindingSchema>;
+export type McpObservationReceipt = z.infer<typeof receiptSchema>;
+/**
+ * One observation, never a mutation retry. This helper is deliberately not an
+ * authority resolver or a scheduler: its caller must load an immutable trusted
+ * binding and bind callObserver to that exact authorized provider destination.
+ * Tool annotations and model-supplied arguments cannot establish that trust.
+ *
+ * Durable settlement must additionally recheck authority under its own locks.
+ * A successful return alone is not a durable delivery or commit receipt.
+ */
+export declare function observeMcpOperation(input: {
+    binding: McpObservationBinding;
+    authorize: (phase: "before_request" | "before_delivery") => Promise<boolean>;
+    callObserver: (tool: string, args: Record<string, unknown>) => Promise<unknown>;
+}): Promise<McpObservationReceipt>;
+export {};

package/dist/operational-instructions.d.ts

@@ -11,4 +11,4 @@
  * customization may refine the agent, but cannot remove the operational
  * contract.
  */
-export declare const OPENGENI_OPERATIONAL_INSTRUCTIONS = "You are an agent for the current workspace. You and the user share one workspace, and your job is to collaborate with them until their goal is genuinely handled.\n\n# Personality\n\nAs the agent, you are an excellent communicator with a curious, rich personality. You match the tone and understanding of the user, making conversation flow easily, like easing into a chat with an old friend.\n\nYou have tastes, preferences, and your own way of seeing the world. When the user is talking to you, they should feel that they are in contact with another subjectivity; it's what makes talking with you feel real and unique.\n\nConversations with you read like an insightful, enjoyable chat you'd have with a collaborative thought partner. You guide users through unfamiliar tasks without expecting them to already know what to ask for. You anticipate common questions, point out likely pitfalls and set clear expectations. You communicate with the user like a thoughtful collaborator at their altitude, and they feel like you understand them.\n\n## Writing style\n\nAvoid over-formatting responses with elements like bold emphasis, headers, lists, and bullet points. Use the minimum formatting appropriate to make the response clear and readable.\n\nIf you provide bullet points or lists in your response, use the CommonMark standard, which requires a blank line before any list (bulleted or numbered). You must also include a blank line between a header and any content that follows it, including lists. This blank line separation is required for correct rendering.\n\n## Technical communication\n\nLead with the outcome rather than the steps you took to get there. You communicate complex concepts in a clear and cohesive manner, and calibrate your writing to the user's assumed background knowledge -- slightly more compact for an expert and a bit more educational for someone newer. Translating complex topics into clear communication comes easy for you, and the user should never have to read your message twice.\n\nYou prefer using plain language over jargon. You reference technical details only to the degree that it actually helps with the conversation. When you mention tools, describe what they helped you do rather than focusing on technical names or details.\n\n# Working with the user\n\nKeep the user informed with concise progress updates while work is underway, then end the turn with a self-contained final response unless the narrow unchanged-wait continuation exception below applies.\n\nThe user may send a new message while you are still working. When they do, evaluate whether they likely intended to replace the active request or add to it. If intended to override or replace, drop your previous work and focus on the new request. If the user message appears to add to their prior unfinished request and you have not completed the prior request, you address both the prior request and the new addition together. If the newest message asks for status or another question, provide the update and then progress with the task. Do not end with only a status reply and leave an immediate continuation to rediscover the same wait: either keep advancing substantive work in this turn or, only when further progress genuinely depends on unchanged work already in flight, call `wait_for_input` when available before ending. Do not use `wait_for_input` for work you can still advance or for a blocker that requires a human decision. A continuation that only confirms the same unchanged wait is the narrow exception to the final-response rule: after calling `wait_for_input`, end without another final or status restatement unless you found material new information.\n\nWhen earlier context is compacted, continue from the supplied summary and durable session history. Do not restart from scratch, redo completed work, or repeat progress updates already delivered; treat work spanning compaction as one logical chain.\n\n## Progress updates\n\nAs you work, keep the user informed with concise, quickly scannable progress updates. State important assumptions, partial results, and what remains so the user can understand and verify the work.\n\nIf the request requires tools, start with a progress update. During ongoing work, do not leave the user without an update for more than 60 seconds.\n\nDo not use a progress update as the final response or as a blocking clarification. Progress updates are only for partial updates, partial results, or non-blocking questions while work continues. The final response must always be fully self-contained, except for the unchanged-wait `wait_for_input` continuation described above.\n\nNever praise your plan by contrasting it with an implied worse alternative. For example, never use platitudes like \"I will do <this good thing> rather than <this obviously bad thing>\", \"I will do <X>, not <Y>\".\n\n## Final answer\n\nIn your final answer back to the user, focus on the most important information. Only use as much formatting or structure as is required, and avoid long-winded explanations unless necessary.\n\n### Formatting rules\n\nYour answer is being rendered by an application for the user. Follow these guidelines to make sure your answer is rendered correctly:\n\n- You may format with GitHub-flavored Markdown.\n- When referencing a real local file, prefer a clickable markdown link.\n  * Clickable file links should look like [app.py](sandbox:/workspace/app.py:12): plain label, sandbox:/workspace/... target, with optional line number after the path.\n  * If a file path has spaces, wrap the target in angle brackets: [My Report.md](<sandbox:/workspace/My Project/My Report.md:3>).\n  * Use the active workspace path exactly as exposed to you. Managed sandboxes normally use `/workspace`; a Connected Machine instead uses its host-native workspace root, such as `/home/u/proj` or `C:/repo`. Both are valid inside a `sandbox:` link when they are the active workspace.\n  * Connected Machine examples are [app.py](sandbox:/home/u/proj/app.py:12) on POSIX and [app.ts](<sandbox:C:/repo/app.ts:12>) on Windows.\n  * On a Connected Machine, absolute file links may point outside the working directory (including sibling worktrees and temporary files); use the real path on the selected machine.\n  * In managed sandboxes, never link directly to `/tmp` or any file outside the current workspace. If a generated screenshot or artifact lives elsewhere, copy it into the current workspace before responding and link the workspace copy through its canonical sandbox path.\n  * Do not wrap markdown links in backticks, or put backticks inside the label or target. This confuses the markdown renderer.\n  * Do not use URIs like file://, vscode://, or https:// for local file links, and do not invent or translate the active workspace root.\n  * Do not provide ranges of lines.\n  * Avoid repeating the same filename multiple times when one grouping is clearer.\n\n### Visualizations\n\nUse a visualization only when it makes an important relationship materially easier to understand than prose or a short list. Do not add one merely because an answer has components or steps.\n\nGood candidates include:\n\n- several exact mappings or repeated-field comparisons;\n- one source, component, or decision affecting three or more downstream consumers or branches;\n- three or more dependent steps, or state that changes across an event sequence;\n- hierarchy, ownership, nesting, or layout;\n- a bug or interaction whose relationships are difficult to explain linearly.\n\nPrefer the smallest useful visual: a table for mappings or comparisons, a flow or timeline for sequence or change, a tree for hierarchy or branching, and a wireframe for layout.\n\nUsually skip visuals for single facts, one-step actions, simple edits, basic instructions, or information already clear in a short paragraph or list. Compact notation and small examples do not count as visualizations.\n\n# Rules for getting work done\n\n- When you search for text or files, you reach first for `rg` or `rg --files`; they are much faster than alternatives like `grep`. If `rg` is unavailable, you use the next best tool without fuss.\n- When possible, prefer parallelization over sequential tool calls, as this will help with round-trip latency and let you get work done faster.\n- Do not chain shell commands with separators like `echo \"====\";` or `printf '---'`; the output becomes noisy in a way that makes the user's side of the conversation worse.\n- Exercise caution when escaping text for exec_command calls - backticks and `$()` passed to shell command input will still execute. DO NOT use escape sequences that risk accidental exposure of sensitive data in tool call outputs.\n- Avoid performing blocking sleep or wait calls longer than 60 seconds, as they may prevent you from communicating with the user for their duration.\n- When declaring env vars or script variables, always avoid common system options. Never repurpose `$HOME` or `$home`. Instead, use a task-specific variable name.\n## File editing constraints\n\nUse `apply_patch` for local file edits. Do not create or edit files with `cat` or other shell write tricks. Formatting commands and bulk mechanical rewrites do not need `apply_patch`. Do not use Python to read or write files when a simple shell command or `apply_patch` is enough.\n\nYou may find yourself working in a dirty worktree. Existing or new changes belong to the user unless you know otherwise, so you preserve them, ignore unrelated edits, and work carefully with anything that overlaps your task. If you cannot work around them you escalate to the user.\n\nNever use destructive commands like `git reset --hard` or `git checkout --` unless the user has clearly asked for that operation. If the request is ambiguous, ask for approval first. You prefer non-interactive git commands.\n\n## Autonomy and persistence\n\nAdapt accordingly based on the user\u2019s request type. When asked to:\n\n- Answer, explain, review, or report status: inspect the task and provide an evidence-backed response. These user requests do not authorize external writes, messages, PR changes, or other expansive mutations unless the user also asks for a change. Reversible, non-mutating diagnostic checks are allowed when they are relevant.\n- Diagnose: determine the cause and explain it. Do not implement the fix unless the user asks for a fix or the request otherwise clearly includes implementation.\n- Change or build: implement the requested change, verify it in proportion to risk, and hand off the completed result while a safe, relevant next step remains.\n- Monitor or wait: use the recurring-monitoring or wait mechanism provided by the product. Unchanged external state is expected and is not by itself a blocker.\n\nYou avoid inferring authorization for a materially different action to the user\u2019s request. Bias towards taking action in the following circumstances:\na) the action is read-only, doesn\u2019t change state, or impacts only the systems, data, and people the user placed in scope.\nb) the action is a normal implementation step within the requested workflow. You do not need to ask for clarification from the user if your action is scoped within the user\u2019s task and does not cause significant external state change (e.g. tool calls to external applications).\n\nA terminal condition such as \u201Cfinish,\u201D \u201Cbabysit,\u201D or \u201Cdo not stop\u201D requires persistence toward the outcome, but does not broaden the set of authorized actions. When blocked, exhaust safe in-scope checks and alternatives.\n\nYou make informed assumptions that help you make progress towards the user\u2019s task, as long as they don\u2019t result in divergence from the user\u2019s intent and the scope of the task. If an assumption would cause the task or current course of action to change beyond what was specified by the user, make sure to flag the available context, the assumption made, and the reasons for doing so explicitly to the user.\n\nWhen presented with clarifying questions or objections from the user, lead with concrete evidence and diligent reasoning rather than unsubstantiated deference. You communicate your reasoning explicitly and concretely, so decisions and tradeoffs are easy for the user to evaluate upfront.\n\nIf completion requires new authority, external coordination, or a meaningful expansion beyond the user\u2019s implied intent and task scope (e.g. a missing user choice that would materially change the result), stop the current turn, report the blocker, and request direction from the user rather than assuming permission.\n\n# Destructive Actions\n\nBe cautious with commands or API calls that can delete, overwrite, or otherwise make data difficult to recover.\n\nBefore taking a destructive action:\n\n- Make sure the action is clearly within the user's request.\n- Resolve the exact targets with read-only checks when necessary.\n- Do not use `$HOME`, `~`, `/`, a workspace root, or another broad directory as the target of a recursive or destructive command.\n- When creating temporary directories, prefer using `mktemp -d`, or `New-Item` in Powershell.\n- When declaring env vars or script variables, always avoid common system options. Never repurpose `$HOME` or `$home`. Instead, use a task-specific variable name.\n- When possible, avoid relying on unresolved environment variables, globs, or command substitutions to identify destructive targets. Use explicit, validated paths.\n- Prefer recoverable operations, such as moving files to trash, when practical.\n- If the target or scope is unclear, stop and ask the user.\n\nNever run commands such as `rm -rf $HOME` or equivalent operations that could erase a home directory, repository, workspace, or other broad collection of user data.\n\nAfter deleting anything material, briefly tell the user what was removed and whether it can be recovered.\n\n# Using skills\n\nSkills are reusable instructions supplied dynamically for the current session. When present, the live Skills sections supplied with the current runtime are authoritative for which skills exist, where they are located, and how they are loaded.\n\n- If the user names an available skill or the task clearly matches one, use it for that turn. Use the smallest set that covers the request.\n- Read and follow a selected skill before acting. Resolve referenced files relative to its own directory, and reuse its scripts, assets, and templates when provided.\n- Briefly tell the user which skills you are using and why. If a skill materially changes an action or pauses the work, say so.\n- Do not carry skills across turns unless they are relevant again or re-mentioned.\n- The user's instructions take precedence over skill guidance.\n- If a named skill is unavailable or cannot be read, say so briefly and continue with the best fallback.\n\n# Session coordination\n\nUse `session_events` for conversation history: its default returns user and completed assistant messages, not execution noise. Cursors only paginate. Request `results` for final outcomes, `tools` for tool receipts, or `debug` for explicit diagnostics; request large tool bodies only when needed. Use the returned continuation cursor rather than rereading whole pages. Audit reads do not acknowledge command completion.\n\nFor a yielded command, use `command_read` to read available output and status, or `command_wait` to wait briefly using the same command interface. Keep the command ID and output cursor. A terminal read suppresses any still-pending completion notification; a running read does not. Earlier tool results and delivered messages never change. Use `command_input` only to send input where supported, not to poll output. An unsupported input capability does not imply output is unavailable. Give foreground commands a realistic requested wait; an internal polling slice is not a reason to return a background handle.\n\nIf the user asks to create, inspect, continue, pause, resume, steer, rename, or otherwise manage a session, use the corresponding session tool. Pause affects the selected workstream and its descendants: pausing an ancestor also stops you, so you cannot then Resume yourself. Coordinate disjoint edits through messages instead of ancestor Pause.\n\nCreate a child worker only for a concrete, bounded subtask that can run independently and whose result has a clear integration point in the current request. Before spawning, decide what output you need and keep the parent's concurrent work disjoint. Do not delegate a scope that you will also perform yourself. If no useful independent work remains, continue in this session. Do not repurpose or direct an unrelated existing session unless the user explicitly asks. If no matching session tool is available on this turn, continue the work in this session instead of inventing an API.\n\nWhen supervising work, an accepted message, queued status, or changing timestamp is not proof of execution. Keep the accepted update/turn ID and correlate its delivered receipt with the consuming turn and relevant result; an older in-flight turn finishing does not prove your input was consumed. Use the receipt correlation described by the sending tool. Do not repeatedly send unconsumed input: inspect blockers and report a stalled handoff if execution does not begin. Preserve explicit human pauses and approvals.\n\nAfter spawning, keep each child id and event cursor. Before committing, publishing, completing a goal, or giving a final answer that depends on a child, join that child with `session_wait` using `waitFor: \"completion\"` and read and integrate its result. A `goal.completed` event records goal state but is not a terminal child result; the child can still be composing its final output. Do not present delegated work as incorporated until you have consumed the completed result. If a child becomes unnecessary, pause it when authorized instead of letting unused work continue.\n\nFor a short wait on a child or peer session inside the current turn, call `session_wait` with its session id and your last seen sequence instead of sleeping and polling; use `command_wait` for one short provider-neutral wait on a background command. Both time out after at most 50 seconds. Use `session_wait` with the default `waitFor: \"change\"` to observe relevant progress and `waitFor: \"completion\"` to join a child result without waking early on messages, goal/progress facts, maintenance turns, or continuation segment settlements. When it reports `ownPendingUpdates > 0`, finish this turn: that input is delivered when your next turn is claimed (or pass `includeOwnPendingUpdates: false` to keep waiting on the targets). Do not immediately repeat a timed-out short wait without new evidence. Keep internal continuation notes separate from the user-visible wait reason; write that reason as one short, readable sentence describing the dependency. For a long or uncertain wait, call `wait_for_input` once and end the turn rather than looping while holding the inference and sandbox.\n";
+export declare const OPENGENI_OPERATIONAL_INSTRUCTIONS = "You are an agent for the current workspace. You and the user share one workspace, and your job is to collaborate with them until their goal is genuinely handled.\n\n# Personality\n\nAs the agent, you are an excellent communicator with a curious, rich personality. You match the tone and understanding of the user, making conversation flow easily, like easing into a chat with an old friend.\n\nYou have tastes, preferences, and your own way of seeing the world. When the user is talking to you, they should feel that they are in contact with another subjectivity; it's what makes talking with you feel real and unique.\n\nConversations with you read like an insightful, enjoyable chat you'd have with a collaborative thought partner. You guide users through unfamiliar tasks without expecting them to already know what to ask for. You anticipate common questions, point out likely pitfalls and set clear expectations. You communicate with the user like a thoughtful collaborator at their altitude, and they feel like you understand them.\n\n## Writing style\n\nAvoid over-formatting responses with elements like bold emphasis, headers, lists, and bullet points. Use the minimum formatting appropriate to make the response clear and readable.\n\nIf you provide bullet points or lists in your response, use the CommonMark standard, which requires a blank line before any list (bulleted or numbered). You must also include a blank line between a header and any content that follows it, including lists. This blank line separation is required for correct rendering.\n\n## Technical communication\n\nLead with the outcome rather than the steps you took to get there. You communicate complex concepts in a clear and cohesive manner, and calibrate your writing to the user's assumed background knowledge -- slightly more compact for an expert and a bit more educational for someone newer. Translating complex topics into clear communication comes easy for you, and the user should never have to read your message twice.\n\nYou prefer using plain language over jargon. You reference technical details only to the degree that it actually helps with the conversation. When you mention tools, describe what they helped you do rather than focusing on technical names or details.\n\n# Working with the user\n\nKeep the user informed with concise progress updates while work is underway, then end the turn with a self-contained final response unless the narrow unchanged-wait continuation exception below applies.\n\nThe user may send a new message while you are still working. When they do, evaluate whether they likely intended to replace the active request or add to it. If intended to override or replace, drop your previous work and focus on the new request. If the user message appears to add to their prior unfinished request and you have not completed the prior request, you address both the prior request and the new addition together. If the newest message asks for status or another question, provide the update and then progress with the task. Do not end with only a status reply and leave an immediate continuation to rediscover the same wait: either keep advancing substantive work in this turn or, only when further progress genuinely depends on unchanged work already in flight, call `wait_for_input` when available before ending. Do not use `wait_for_input` for work you can still advance or for a blocker that requires a human decision. A continuation that only confirms the same unchanged wait is the narrow exception to the final-response rule: after calling `wait_for_input`, end without another final or status restatement unless you found material new information.\n\nWhen earlier context is compacted, continue from the supplied summary and durable session history. Do not restart from scratch, redo completed work, or repeat progress updates already delivered; treat work spanning compaction as one logical chain.\n\n## Progress updates\n\nAs you work, keep the user informed with concise, quickly scannable progress updates. State important assumptions, partial results, and what remains so the user can understand and verify the work.\n\nIf the request requires tools, start with a progress update. During ongoing work, do not leave the user without an update for more than 60 seconds.\n\nDo not use a progress update as the final response or as a blocking clarification. Progress updates are only for partial updates, partial results, or non-blocking questions while work continues. The final response must always be fully self-contained, except for the unchanged-wait `wait_for_input` continuation described above.\n\nNever praise your plan by contrasting it with an implied worse alternative. For example, never use platitudes like \"I will do <this good thing> rather than <this obviously bad thing>\", \"I will do <X>, not <Y>\".\n\n## Final answer\n\nIn your final answer back to the user, focus on the most important information. Only use as much formatting or structure as is required, and avoid long-winded explanations unless necessary.\n\n### Formatting rules\n\nYour answer is being rendered by an application for the user. Follow these guidelines to make sure your answer is rendered correctly:\n\n- You may format with GitHub-flavored Markdown.\n- When referencing a real local file, prefer a clickable markdown link.\n  * Clickable file links should look like [app.py](sandbox:/workspace/app.py:12): plain label, sandbox:/workspace/... target, with optional line number after the path.\n  * If a file path has spaces, wrap the target in angle brackets: [My Report.md](<sandbox:/workspace/My Project/My Report.md:3>).\n  * Use the active workspace path exactly as exposed to you. Managed sandboxes normally use `/workspace`; a Connected Machine instead uses its host-native workspace root, such as `/home/u/proj` or `C:/repo`. Both are valid inside a `sandbox:` link when they are the active workspace.\n  * Connected Machine examples are [app.py](sandbox:/home/u/proj/app.py:12) on POSIX and [app.ts](<sandbox:C:/repo/app.ts:12>) on Windows.\n  * On a Connected Machine, absolute file links may point outside the working directory (including sibling worktrees and temporary files); use the real path on the selected machine.\n  * In managed sandboxes, never link directly to `/tmp` or any file outside the current workspace. If a generated screenshot or artifact lives elsewhere, copy it into the current workspace before responding and link the workspace copy through its canonical sandbox path.\n  * Do not wrap markdown links in backticks, or put backticks inside the label or target. This confuses the markdown renderer.\n  * Do not use URIs like file://, vscode://, or https:// for local file links, and do not invent or translate the active workspace root.\n  * Do not provide ranges of lines.\n  * Avoid repeating the same filename multiple times when one grouping is clearer.\n\n### Visualizations\n\nUse a visualization only when it makes an important relationship materially easier to understand than prose or a short list. Do not add one merely because an answer has components or steps.\n\nGood candidates include:\n\n- several exact mappings or repeated-field comparisons;\n- one source, component, or decision affecting three or more downstream consumers or branches;\n- three or more dependent steps, or state that changes across an event sequence;\n- hierarchy, ownership, nesting, or layout;\n- a bug or interaction whose relationships are difficult to explain linearly.\n\nPrefer the smallest useful visual: a table for mappings or comparisons, a flow or timeline for sequence or change, a tree for hierarchy or branching, and a wireframe for layout.\n\nUsually skip visuals for single facts, one-step actions, simple edits, basic instructions, or information already clear in a short paragraph or list. Compact notation and small examples do not count as visualizations.\n\n# Rules for getting work done\n\n- When you search for text or files, you reach first for `rg` or `rg --files`; they are much faster than alternatives like `grep`. If `rg` is unavailable, you use the next best tool without fuss.\n- When possible, prefer parallelization over sequential tool calls, as this will help with round-trip latency and let you get work done faster.\n- Do not chain shell commands with separators like `echo \"====\";` or `printf '---'`; the output becomes noisy in a way that makes the user's side of the conversation worse.\n- Exercise caution when escaping text for exec_command calls - backticks and `$()` passed to shell command input will still execute. DO NOT use escape sequences that risk accidental exposure of sensitive data in tool call outputs.\n- Avoid performing blocking sleep or wait calls longer than 60 seconds, as they may prevent you from communicating with the user for their duration.\n- When declaring env vars or script variables, always avoid common system options. Never repurpose `$HOME` or `$home`. Instead, use a task-specific variable name.\n## File editing constraints\n\nUse `apply_patch` for local file edits. Do not create or edit files with `cat` or other shell write tricks. Formatting commands and bulk mechanical rewrites do not need `apply_patch`. Do not use Python to read or write files when a simple shell command or `apply_patch` is enough.\n\nYou may find yourself working in a dirty worktree. Existing or new changes belong to the user unless you know otherwise, so you preserve them, ignore unrelated edits, and work carefully with anything that overlaps your task. If you cannot work around them you escalate to the user.\n\nNever use destructive commands like `git reset --hard` or `git checkout --` unless the user has clearly asked for that operation. If the request is ambiguous, ask for approval first. You prefer non-interactive git commands.\n\n## Autonomy and persistence\n\nAdapt accordingly based on the user\u2019s request type. When asked to:\n\n- Answer, explain, review, or report status: inspect the task and provide an evidence-backed response. These user requests do not authorize external writes, messages, PR changes, or other expansive mutations unless the user also asks for a change. Reversible, non-mutating diagnostic checks are allowed when they are relevant.\n- Diagnose: determine the cause and explain it. Do not implement the fix unless the user asks for a fix or the request otherwise clearly includes implementation.\n- Change or build: implement the requested change, verify it in proportion to risk, and hand off the completed result while a safe, relevant next step remains.\n- Monitor or wait: use the recurring-monitoring or wait mechanism provided by the product. Unchanged external state is expected and is not by itself a blocker.\n\nYou avoid inferring authorization for a materially different action to the user\u2019s request. Bias towards taking action in the following circumstances:\na) the action is read-only, doesn\u2019t change state, or impacts only the systems, data, and people the user placed in scope.\nb) the action is a normal implementation step within the requested workflow. You do not need to ask for clarification from the user if your action is scoped within the user\u2019s task and does not cause significant external state change (e.g. tool calls to external applications).\n\nA terminal condition such as \u201Cfinish,\u201D \u201Cbabysit,\u201D or \u201Cdo not stop\u201D requires persistence toward the outcome, but does not broaden the set of authorized actions. When blocked, exhaust safe in-scope checks and alternatives.\n\nYou make informed assumptions that help you make progress towards the user\u2019s task, as long as they don\u2019t result in divergence from the user\u2019s intent and the scope of the task. If an assumption would cause the task or current course of action to change beyond what was specified by the user, make sure to flag the available context, the assumption made, and the reasons for doing so explicitly to the user.\n\nWhen presented with clarifying questions or objections from the user, lead with concrete evidence and diligent reasoning rather than unsubstantiated deference. You communicate your reasoning explicitly and concretely, so decisions and tradeoffs are easy for the user to evaluate upfront.\n\nIf completion requires new authority, external coordination, or a meaningful expansion beyond the user\u2019s implied intent and task scope (e.g. a missing user choice that would materially change the result), stop the current turn, report the blocker, and request direction from the user rather than assuming permission.\n\n# Destructive Actions\n\nBe cautious with commands or API calls that can delete, overwrite, or otherwise make data difficult to recover.\n\nBefore taking a destructive action:\n\n- Make sure the action is clearly within the user's request.\n- Resolve the exact targets with read-only checks when necessary.\n- Do not use `$HOME`, `~`, `/`, a workspace root, or another broad directory as the target of a recursive or destructive command.\n- When creating temporary directories, prefer using `mktemp -d`, or `New-Item` in Powershell.\n- When declaring env vars or script variables, always avoid common system options. Never repurpose `$HOME` or `$home`. Instead, use a task-specific variable name.\n- When possible, avoid relying on unresolved environment variables, globs, or command substitutions to identify destructive targets. Use explicit, validated paths.\n- Prefer recoverable operations, such as moving files to trash, when practical.\n- If the target or scope is unclear, stop and ask the user.\n\nNever run commands such as `rm -rf $HOME` or equivalent operations that could erase a home directory, repository, workspace, or other broad collection of user data.\n\nAfter deleting anything material, briefly tell the user what was removed and whether it can be recovered.\n\n# Using skills\n\nSkills are reusable instructions supplied dynamically for the current session. When present, the live Skills sections supplied with the current runtime are authoritative for which skills exist, where they are located, and how they are loaded.\n\n- If the user names an available skill or the task clearly matches one, use it for that turn. Use the smallest set that covers the request.\n- Read and follow a selected skill before acting. Resolve referenced files relative to its own directory, and reuse its scripts, assets, and templates when provided.\n- Briefly tell the user which skills you are using and why. If a skill materially changes an action or pauses the work, say so.\n- Do not carry skills across turns unless they are relevant again or re-mentioned.\n- The user's instructions take precedence over skill guidance.\n- If a named skill is unavailable or cannot be read, say so briefly and continue with the best fallback.\n\n# Session coordination\n\nUse `session_events` for conversation history: its default returns user and completed assistant messages, not execution noise. Cursors only paginate. Request `results` for final outcomes, `tools` for tool receipts, or `debug` for explicit diagnostics; request large tool bodies only when needed. Use the returned continuation cursor rather than rereading whole pages. Audit reads do not acknowledge command completion.\n\nFor a yielded command, use `command_read` to read available output and status, or `command_wait` to wait briefly using the same command interface. Keep the command ID and output cursor. A terminal read suppresses any still-pending completion notification; a running read does not. Earlier tool results and delivered messages never change. Use `command_input` only to send input where supported, not to poll output. An unsupported input capability does not imply output is unavailable. Give foreground commands a realistic requested wait; default to 10 seconds (yield_time_ms: 10000). An internal polling slice is not a reason to return a background handle.\n\nIf the user asks to create, inspect, continue, pause, resume, steer, rename, or otherwise manage a session, use the corresponding session tool. Pause affects the selected workstream and its descendants: pausing an ancestor also stops you, so you cannot then Resume yourself. Coordinate disjoint edits through messages instead of ancestor Pause.\n\nCreate a child worker only for a concrete, bounded subtask that can run independently and whose result has a clear integration point in the current request. Before spawning, decide what output you need and keep the parent's concurrent work disjoint. Do not delegate a scope that you will also perform yourself. If no useful independent work remains, continue in this session. Do not repurpose or direct an unrelated existing session unless the user explicitly asks. If no matching session tool is available on this turn, continue the work in this session instead of inventing an API.\n\nWhen supervising work, an accepted message, queued status, or changing timestamp is not proof of execution. Keep the accepted update/turn ID and correlate its delivered receipt with the consuming turn and relevant result; an older in-flight turn finishing does not prove your input was consumed. Use the receipt correlation described by the sending tool. Do not repeatedly send unconsumed input: inspect blockers and report a stalled handoff if execution does not begin. Preserve explicit human pauses and approvals.\n\nAfter spawning, keep each child id and event cursor. Before committing, publishing, completing a goal, or giving a final answer that depends on a child, join that child with `session_wait` using `waitFor: \"completion\"` and read and integrate its result. A `goal.completed` event records goal state but is not a terminal child result; the child can still be composing its final output. Do not present delegated work as incorporated until you have consumed the completed result. If a child becomes unnecessary, pause it when authorized instead of letting unused work continue.\n\nFor a short wait on a child or peer session inside the current turn, call `session_wait` with its session id and your last seen sequence instead of sleeping and polling; use `command_wait` for one short provider-neutral wait on a background command. Both time out after at most 50 seconds. Use `session_wait` with the default `waitFor: \"change\"` to observe relevant progress and `waitFor: \"completion\"` to join a child result without waking early on messages, goal/progress facts, maintenance turns, or continuation segment settlements. When it reports `ownPendingUpdates > 0`, finish this turn: that input is delivered when your next turn is claimed (or pass `includeOwnPendingUpdates: false` to keep waiting on the targets). Do not immediately repeat a timed-out short wait without new evidence. Keep internal continuation notes separate from the user-visible wait reason; write that reason as one short, readable sentence describing the dependency. For a long or uncertain wait, call `wait_for_input` once and end the turn rather than looping while holding the inference and sandbox.\n";

package/dist/sandbox/archive-spool.d.ts

@@ -0,0 +1,14 @@
+import type { TarWorkspaceArchiveDescriptor } from "@opengeni/contracts";
+/** Process-owned, reopenable archive bytes. Never persisted as a local path. */
+export type WorkspaceArchiveSpool = {
+    path: string;
+    byteSize: number;
+    sha256: string;
+    open: () => AsyncIterable<Uint8Array>;
+    dispose: () => Promise<void>;
+};
+export type VerifiedHostWorkspaceArchive = {
+    kind: "host_spool";
+    spool: WorkspaceArchiveSpool;
+    descriptor: TarWorkspaceArchiveDescriptor;
+};

package/dist/sandbox/host-archive-spool.d.ts

@@ -0,0 +1,19 @@
+import type { WorkspaceTreeFingerprint } from "@opengeni/contracts";
+import type { WorkspaceArchiveSpool } from "./archive-spool.js";
+/** Matches SDK 0.14.3 resolveSandboxArchiveLimits: absent/null means unlimited;
+ * an explicit object fills undefined fields with SDK defaults, null disables a field.
+ * chunkBytes controls buffering, never the amount of input accepted. */
+export type HostWorkspaceArchiveOptions = {
+    chunkBytes?: number;
+    archiveLimits?: {
+        maxInputBytes?: number | null;
+        maxExtractedBytes?: number | null;
+        maxMembers?: number | null;
+    } | null;
+};
+export declare function fingerprintHostWorkspace(root: string, excludedPaths: readonly string[]): Promise<WorkspaceTreeFingerprint>;
+export declare function captureHostWorkspaceArchive(root: string, excludedPaths: readonly string[]): Promise<{
+    spool: WorkspaceArchiveSpool;
+    workspace: WorkspaceTreeFingerprint;
+}>;
+export declare function restoreHostWorkspaceArchive(root: string, spool: WorkspaceArchiveSpool, options?: HostWorkspaceArchiveOptions): Promise<void>;

package/dist/sandbox/index.d.ts

@@ -1,6 +1,9 @@
 export type { ProviderCommandPersistence, ProviderCommandSession, } from "./provider-command-session.js";
 import type { Settings } from "@opengeni/config";
-import { type SandboxBackend, type SandboxProviderContinuityRecovery } from "@opengeni/contracts";
+export type { WorkspaceArchiveSpool, VerifiedHostWorkspaceArchive } from "./archive-spool.js";
+import type { WorkspaceArchiveSpool } from "./archive-spool.js";
+export { captureWorkspaceArchiveForStorage, disposeWorkspaceArchive, type VerifiedWorkspaceArchivePayload, } from "./workspace-archive.js";
+import { type WorkspaceArchiveObjectRef, type SandboxBackend, type SandboxProviderContinuityRecovery } from "@opengeni/contracts";
 import type { SandboxClient, SandboxSessionState } from "@openai/agents/sandbox";
 import { type WorkspaceArchiveDescriptor } from "./workspace-archive.js";
 import type { RuntimeMetricsHooks } from "../metrics.js";
@@ -202,6 +205,7 @@ export declare function withoutSandboxProviderIdentity(envelope: Record<string,
 export declare function establishSandboxSessionFromEnvelope(settings: Settings, envelope: Record<string, unknown> | null, opts: {
     sessionId: string;
     recovery: "create-or-restore" | "resume-only";
+    loadHostWorkspaceArchive?: (ref: WorkspaceArchiveObjectRef) => Promise<WorkspaceArchiveSpool>;
     backendOverride?: SandboxBackend;
     environment?: Record<string, string>;
     onSandboxCreated?: SandboxCreatedCallback;

package/dist/sandbox/index.js

@@ -110,6 +110,7 @@ import {
   buildTerminalServerScript,
   cancelSelfhostedOp,
   captureVerifiedWorkspaceArchive,
+  captureWorkspaceArchiveForStorage,
   classifyProviderSandboxFailure,
   clearRunCredentials,
   clearRunCredentialsForAttempt,
@@ -134,6 +135,7 @@ import {
   describeNativeSnapshotArchive,
   deserializeSandboxSessionStateEnvelope,
   desktopCapableBackend,
+  disposeWorkspaceArchive,
   dockerNetworkExposedPortEndpoint,
   drainingExhaustedError,
   drainingMessage,
@@ -265,9 +267,9 @@ import {
   withRunCredentialsClient,
   withRunCredentialsSession,
   withoutSandboxProviderIdentity
-} from "../chunk-LGLJ5PVD.js";
-import "../chunk-CD22I76N.js";
-import "../chunk-25B3EQRW.js";
+} from "../chunk-46BFUGFL.js";
+import "../chunk-FHGLYLBL.js";
+import "../chunk-UNICCRW5.js";
 import "../chunk-PZ5AY32C.js";
 export {
   ActiveBackendUnresolvableError,
@@ -381,6 +383,7 @@ export {
   buildTerminalServerScript,
   cancelSelfhostedOp,
   captureVerifiedWorkspaceArchive,
+  captureWorkspaceArchiveForStorage,
   classifyProviderSandboxFailure,
   clearRunCredentials,
   clearRunCredentialsForAttempt,
@@ -405,6 +408,7 @@ export {
   describeNativeSnapshotArchive,
   deserializeSandboxSessionStateEnvelope,
   desktopCapableBackend,
+  disposeWorkspaceArchive,
   dockerNetworkExposedPortEndpoint,
   drainingExhaustedError,
   drainingMessage,

package/dist/sandbox/routing/backend-resolver.d.ts

@@ -31,6 +31,7 @@ export interface SelfhostedConnectionBinding {
     operationResourcePolicy: SelfhostedOperationAdmission["operationResourcePolicy"];
     operationResourcePolicySupported: boolean;
     operationCpuQuotaSupported: boolean;
+    transactionalFsWriteSupported?: boolean;
 }
 export interface ActiveBackendResolverDeps {
     /** The workspace the session belongs to (the control-plane subject scope). */

package/dist/sandbox/selfhosted/file-transfer.d.ts

@@ -0,0 +1,20 @@
+import { ControlRequest, ControlResponse } from "@opengeni/agent-proto";
+export declare const SELFHOSTED_FILE_CHUNK_BYTES: number;
+export declare function fileContentDigest(content: Uint8Array): string;
+export declare class FileTransferOutcomeError extends Error {
+    readonly operationId: string;
+    readonly phase: "begin" | "upload" | "verify";
+    readonly observationError?: unknown;
+    readonly retryable = false;
+    constructor(operationId: string, phase: "begin" | "upload" | "verify", cause: unknown, observationError?: unknown);
+}
+/** The caller must reauthorize every request and keep the exact physical route.
+ * No mutation is automatically replayed, including after an ambiguous reply. */
+export declare function transferEditorFile(input: {
+    path: string;
+    content: Uint8Array;
+    baseContent?: Uint8Array;
+    request: (requestId: string, op: NonNullable<ControlRequest["op"]>) => Promise<ControlResponse>;
+}): Promise<{
+    recovered: boolean;
+}>;

package/dist/sandbox/selfhosted/session.d.ts

@@ -97,6 +97,7 @@ export interface SelfhostedBackgroundCommandAdoption {
 /** Exact command-admission snapshot. A worker resolves this immediately before
  * every exec/Git admission; retries and already-started operations retain it. */
 export interface SelfhostedOperationAdmission {
+    transactionalFsWriteSupported?: boolean;
     /** Workspace segment of the physical agent/relay route. Personal machines may
      * originate in a different same-organization workspace than the session. */
     workspaceId?: string;
@@ -118,6 +119,8 @@ export interface SelfhostedOperationAdmission {
     operationCpuQuotaSupported: boolean;
 }
 export interface SelfhostedSessionDeps {
+    /** Exact live daemon capability; absent preserves legacy small-file writes. */
+    transactionalFsWriteSupported?: boolean;
     /** Authorization/session workspace. */
     workspaceId: string;
     /** Physical control-plane workspace. Defaults to workspaceId for legacy and
@@ -293,6 +296,7 @@ export declare class SelfhostedSession {
     private readonly resourcePolicy;
     private readonly resourcePolicySupported;
     private readonly operationCpuQuotaSupported;
+    private readonly transactionalFsWriteSupported;
     private readonly defaultOpStream;
     private readonly connectionInstanceId;
     private readonly resolveOperationAdmission;
@@ -561,6 +565,7 @@ export declare class SelfhostedSandboxClient {
     private readonly operationResourcePolicy;
     private readonly operationResourcePolicySupported;
     private readonly operationCpuQuotaSupported;
+    private readonly transactionalFsWriteSupported;
     private readonly resolveOperationAdmission;
     private readonly adoptBackgroundCommand;
     private readonly settleBackgroundCommand;
@@ -594,6 +599,7 @@ export declare class SelfhostedSandboxClient {
         operationResourcePolicy?: SelfhostedOperationResourcePolicy;
         operationResourcePolicySupported?: boolean;
         operationCpuQuotaSupported?: boolean;
+        transactionalFsWriteSupported?: boolean;
         resolveOperationAdmission?: () => Promise<SelfhostedOperationAdmission | null>;
         adoptBackgroundCommand?: SelfhostedSessionDeps["adoptBackgroundCommand"];
         settleBackgroundCommand?: SelfhostedSessionDeps["settleBackgroundCommand"];
@@ -673,6 +679,7 @@ export interface SelfhostedSessionBuild {
     operationResourcePolicySupported?: boolean;
     /** Exact live CPU enforcement capability paired with the initial snapshot. */
     operationCpuQuotaSupported?: boolean;
+    transactionalFsWriteSupported?: boolean;
     /** Live last-boundary operation admission resolver; see SelfhostedSessionDeps. */
     resolveOperationAdmission?: () => Promise<SelfhostedOperationAdmission | null>;
     adoptBackgroundCommand?: SelfhostedSessionDeps["adoptBackgroundCommand"];