OMP Workbook

Read the source. Follow the evidence.

Sharing is a separate disclosure decision

Noor has reviewed a local packet. That does not automatically authorize uploading it.

This chapter is a decision and evidence exercise. Do not execute /share as part of the workbook. No live upload is needed to learn the boundaries.

Milestone: Identify the route before authorizing disclosure

Need. Noor may eventually need a link for an authorized reviewer.

Obstacle. The same human command can use a default encrypted snapshot or a custom executable handler with a different data contract.

Exact action: review the effective sharing settings and whether the active agent directory contains a custom share script. Then identify what data that route would receive. Do not invoke sharing to discover its policy.

The supplied settings schema places sharing controls under Interaction / Collab:

SettingCurrent default or sourceMeaning
share.storeblobUpload the encrypted snapshot to the share server.
share.serverUrlDEFAULT_SHARE_URLUpload/viewer base. The accompanying operation document names https://my.omp.sh/s.
share.redactSecretstruePass the session’s secret obfuscator to default sharing when available.
secrets.enabledfalseSDK creation only builds the normal secret obfuscator when enabled.

The defining body of the imported DEFAULT_SHARE_URL constant is not included in the source bundle. Treat the effective installed share.serverUrl as authoritative rather than assuming a documented endpoint.

Global settings, project settings, explicit overlays, and runtime overrides can affect effective values. A value in one config file is not necessarily the current effective value, especially after a project-scope change.

Current default correction: GitHub gist is not the default or preferred route in the supplied schema. share.store defaults to blob. There is no supplied --gist flag.

Default sharing and custom sharing are different contracts

RouteData contract
Default encrypted sharingBuilds a JSON snapshot directly from the manager and optional current agent state; optionally applies the typed secret-redaction pass; compresses and encrypts it.
TUI custom handlerReceives the path to an ordinary temporary HTML export. It is not handed the default encrypted/redacted snapshot.
Shared non-TUI builtinCalls default shareSession directly; it does not load the custom TUI share script.

Default buildShareSnapshot calls buildSessionData. It does not collect adjacent subagent JSONL files. The supplied interception check confirmed that omission.

Ordinary HTML export, including the TUI custom-handler input, does collect adjacent nested transcripts by default.

This does not mean default sharing contains no subagent-derived information. Parent journal entries can already contain task inputs, results, and quoted output.

Default sharing can work for an in-memory session because it builds the snapshot from the manager’s entries without requiring a session file. A custom TUI handler still depends on HTML export, so a manager without a session file can fail before the handler runs. There is no automatic fallback from that custom path.

What changes? An approved share would create a separate disclosure artifact or handler effect, not a new conversation identity.

What does not change? The default snapshot does not append sharing entries to the source journal. Encryption and redaction operate on the outgoing representation, not as an erasure operation on the original.

Recorded check. Intercepted default sharing encrypted a fictional snapshot, removed a configured synthetic secret, retained an unmatched fictional string, left source entries unchanged, and did not collect adjacent nested sessions.

Self-check. Can Noor assume that a custom handler receives the same sanitized data as default sharing?

Answer: No. It receives ordinary HTML under a separate contract.

Redaction is conditional and field-specific

share.redactSecrets: true is not a universal privacy guarantee.

The current default-share path skips its typed redaction pass when there is no obfuscator or the obfuscator reports no configured/recognized secret handling. With secrets.enabled at its schema default of false, the normal SDK path does not create that obfuscator.

When active, the typed pass rewrites selected text-bearing fields, including relevant:

  • Header title and cwd.
  • Current system prompt and tool descriptions.
  • Message text, stored thinking text, tool-call arguments, and error text.
  • Tool-result content and execution output.
  • File-mention paths and contents.
  • Summaries, labels, and title-change text.

It drops specified opaque provider replay material and untyped payloads, such as certain details, data, output schemas, and compaction preserve data, rather than attempting a universal recursive scrub.

Important limits remain:

  • Unknown or unconfigured strings can survive.
  • Image bytes remain intact before the later size-trimming pass.
  • The typed header walk does not rewrite every possible path-bearing field. For example, additionalDirectories is not rewritten by redactShareHeader.
  • IDs, parent references, and pseudonymous account-related metadata can still be identifying or linkable.
  • Dropping a metadata field can also remove context a reviewer would otherwise need.

The recorded check confirmed configured-secret removal, opaque tool-result-details omission, small-image preservation, and complete skipping of redaction with an absent or empty obfuscator.

Local HTML export does not run this share-redaction pass. A transcript may already contain some obfuscated content, but that is not the same as auditing the output artifact.

Encryption protects a different boundary

Default sharing:

  1. Builds the snapshot.
  2. Applies the configured redaction pass when available.
  3. Gzips the JSON.
  4. Seals it using a fresh AES-256-GCM key and a 12-byte IV.
  5. Uploads the sealed blob.
  6. Returns a viewer URL containing the key in its fragment after #.

The recorded intercepted POST URL did not contain the fragment key. Ordinary HTTP requests do not carry URL fragments automatically.

But possession of the complete link grants decryption access. A recipient can forward it. Messages, screenshots, browser history, and other places where the complete link is stored can become access-bearing copies.

Do not turn “the key is in the fragment” into “no client-side code or recipient can disclose it.” The viewer is part of the trust boundary.

Encryption is not redaction, anonymity, access approval, or secure deletion.

Size trimming is loss, not privacy review

The production sealed-byte budgets are:

  • Share server: 1,000,000 bytes.
  • Gist route: 5,000,000 bytes, before base64 expansion.

When a snapshot is too large, the implementation progressively:

  1. Replaces large inline image payloads and large data URLs.
  2. Caps long strings at lengths of 32,768, 8,192, 2,048, then 512.
  3. Removes oldest entries by repeatedly halving the retained entry list while more than four entries remain.
  4. Throws if the result still cannot fit.

The string caps are implementation string-length caps, distinct from the final sealed-byte budget.

The result reports truncation, and the command can display a note that large content was trimmed. Trimming can remove evidence or qualifiers. It is not a secret detector and does not make surviving content safe.

The recorded trimming tests used a smaller explicit 4,000-byte budget, confirmed image/text trimming and unchanged originals, and checked an impossible-budget error. They did not upload a production-size packet.

Gist fallback is not custom-handler fallback

Optional share.store: gist tries the gist route when gh is installed and authenticated. It stores the sealed blob base64-encoded as session.ompshare.txt in a secret gist.

If gh is unusable or gist creation fails, default sharing can fall back to the share server.

That fallback matters for disclosure policy: approving one destination is not automatically approving the fallback destination.

Recorded check. A deliberately unauthenticated fake gh received only auth status. No gist was created. The code fell back to one intercepted server POST.

By contrast, a TUI custom handler is discovered in the active getAgentDir() in this order:

  1. share.ts
  2. share.js
  3. share.mjs

The first existing candidate must default-export the expected function. The ordinary default location is under ~/.omp/agent, but profile/agent-directory resolution can change that location.

If loading fails, the command errors and returns. If execution throws, it errors and returns. Neither failure falls back to default sharing.

A custom handler is executable code, not a declarative upload destination. Have its policy reviewed by its maintainer rather than assuming the default encryption or redaction settings constrain it.

Its result can be:

  • A URL string.
  • An object with optional url and/or message.
  • undefined, which produces a generic shared status.

A generic status is not independent proof that a handler uploaded anything.

Milestone: Interpret cancellation without assuming revocation

Need. Noor wants to stop a sharing action.

Obstacle. Restoring the editor and cancelling transport work are different events.

This is a recorded-boundary exercise, not an instruction to start an upload and press Escape.

The TUI loader has an abort signal, but handleShareCommand does not pass that signal into default shareSession or the custom callback.

The recorded default sequence was:

  1. An intercepted POST began and was held pending.
  2. The real loader handled Escape.
  3. The UI reported Share cancelled.
  4. No transport abort signal had been supplied.
  5. The held operation completed afterward.
  6. The late URL was not displayed or opened.

The recorded custom sequence likewise completed a callback effect after Escape. Its temporary HTML remained while the handler was pending and was removed after settlement.

What changes on Escape? The editor is restored, the loader is cancelled, and later result display/opening is suppressed.

What does not follow? A started upload or custom effect is not necessarily stopped, undone, or revoked.

Temporary custom HTML is removed in finally after settlement, with cleanup errors ignored. A crash or failed cleanup can leave it behind. “Temporary” is not an erasure guarantee.

Failure and recovery. Treat a cancelled or ambiguous share as possibly completed until the destination is checked through an approved process. Do not repeat the share merely to recover a missing URL. Do not use /clear, /new, or /drop as upload revocation.

A server error also does not establish that nothing reached the remote system. The supplied HTTP-error check observed one intercepted POST and error propagation, not a universal remote non-delivery guarantee.

No generic revoke/delete-link workflow is established by this evidence.

Self-check. Noor sees Share cancelled. Is that enough to tell an owner that nothing was uploaded?

Answer: No.

Source anchors: packages/coding-agent/src/export/share.ts — buildShareSnapshot, redactShareHeader, redactShareEntry, redactShareMessage, shareSession, sealToFit, tryCreateGist, uploadToServer; packages/coding-agent/src/export/custom-share.ts — getCustomSharePath, loadCustomShare; packages/coding-agent/src/config/settings-schema.ts — sharing and secrets settings; packages/coding-agent/src/sdk.ts — obfuscator construction; packages/coding-agent/src/modes/controllers/command-controller.ts — handleShareCommand; packages/tui/src/components/cancellable-loader.ts — handleInput.

Sessions, resets, and reviewable history · Source chapter: continuity/sharing-is-a-separate-disclosure-decision. Original evidence remains scoped to its recorded snapshot.

Read this chapter as Markdown

Your lesson ticks

A self-reported reading checklist, not proof of real OMP behavior. Only these ticks are saved in this browser. Reading a milestone does not resume, fork, reset or export a session.

Chapters I have worked through
Start here 1
Sessions, resets, and reviewable history 19
Memory and reusable knowledge 14
Tangent work and live control 17
Tool permissions and approvals 15
Extensions inside those boundaries 23
Connections and next steps 8
0 of 97 checked

Checklist saving needs JavaScript and available browser storage.