Skip to content

Latest commit

 

History

History
187 lines (114 loc) · 29.4 KB

usage.md

File metadata and controls

187 lines (114 loc) · 29.4 KB

Usage and compatibility

Back to README

Prerequisite

Before installing the skill, make sure session-peer 0.9.1 or newer is installed and check its version. The example below uses pipx; if the runtime is already installed, skip the install command and run only the version check:

pipx install session-peer
session-peer --version

See the session-peer installation options for uv, pip, the POSIX standalone installer, and native Windows setup. Keep using the same package manager for upgrades.

The skill documents basic commands shared by session-peer 0.9.1 and newer. --allow-inactive-codex-home and --relay-login require session-peer 1.0.0 or newer. macOS/Linux receiver policy codexBin and Relay diagnostics correlated by attemptId require session-peer 1.0.1 or newer. The optional paired-device transport requires the session-peer[relay] extra (Unix, Python 3.11+).

The published Python CLI coverage reference is session-peer 1.4.0.

Existing Relay runtime and paired discovery

Before diagnosing missing paired support, identify the operator-approved session-peer invocation and check its session-peer version/help. Check the Python interpreter version separately when needed. A default standalone CLI and an existing Relay-capable service environment can be separate installations on the same machine. A dependency error from one executable is not proof that no suitable environment is installed, and is not by itself a reason to reinstall or re-pair.

Inspect only operator-known launchers/service definitions or explicitly supplied environment paths, using the minimum non-secret metadata needed to identify the interpreter/package environment and state context. Do not scan arbitrary private/credential directories or print credentials. Reading a service definition does not authorize running its startup command, restarting it or executing a newly discovered interpreter. Have the operator review/select the existing runtime before using it; ask the operator to resolve ambiguous runtimes or state directories. Preserve the existing package manager, interpreter, extras, identities, keys and permissions.

Once the runtime and initialized state have been explicitly selected, the existing lookup workflow is:

<relay-runtime> device peers --state <existing-state>
<relay-runtime> list --device <fingerprint> \
  --device-state <existing-state> --device-route direct --json

Substitute operator-reviewed values before using these examples; angle-bracket tokens are placeholders. <relay-runtime> is the approved CLI invocation in the existing environment, not a discovered service startup command. <existing-state> must be the exact known initialized state, not a path guessed for a probe. These are lookup/discovery operations with no native message submission, but they can acquire store locks and perform existing schema/metadata maintenance; they are not a promise of filesystem-read-only access. Do not run them against missing, incomplete or ambiguous state.

Use the exact stored peer/device identifier for <fingerprint> and inspect its stored status. The stored identifier is not proof of remote reachability or permission, and must not be replaced with a guessed key value or a similar label. list --device selects one receiver; its current policy exposes only authorized target aliases. It does not list every native session on that machine. Default list discovers locally; for ordinary local/SSH discovery, --all includes stale/archived records rather than all paired receivers. Do not advertise a proposed aggregate discovery flag as available.

The example explicitly selects an already configured Direct route. It is not a universal connectivity test or a reason to rewrite endpoints. When another route is intentionally selected, retain its existing Relay admission and route requirements. device routes changes stored peer routes; it is not a read-only connectivity check. See the fixed paired list/send/reconciliation reference and route-update contract.

Keep the same selected runtime and initialized state when selecting the exact peer and permitted alias, performing the existing dry-run, and sending once only when the user's workflow authorizes it. Preserve each result's provenance. queued, submitted and receiverAccepted are not consumption or receipt ACK; receiver acceptance can describe a successful lookup/dry-run without any native submission. An unknown outcome never authorizes resend. Do not implicitly install, initialize identity/state, re-pair, repair permissions, restart services, log in or activate a native session to make discovery succeed. A standalone update does not update a separate receiver package environment; a runtime update does not update this independently managed skill.

Runtime 1.0.3 security and operations

Use Python runtime 1.0.3 or newer for its security fixes. The metadata minimum and full versions describe CLI compatibility, not the version recommended for security. Before using SSH, review the v1.0.3 connection-option rules: the complete supplied option list is checked against an allowlist before SSH runs. Use KEY=value for -o, host-style jump targets, and only yes, ask, or accept-new for StrictHostKeyChecking; SSH URI jumps, + in usernames, spaced -o 'Key value', command hooks, alternate config/control socket paths, and known-hosts file overrides are refused. Existing user/system SSH config remains an operator trust boundary, not a sandbox.

Release-backed standalone installation (install.sh) and local session-peer update verify immutable GitHub release assets and provenance. For these checks, follow the installer guidance: use authenticated GitHub CLI (gh) 2.102.0 or later, and authenticate with gh auth login or GH_TOKEN. Version 2.102.0 is the tested baseline; the earliest version supporting all verification flags has not been established. Follow the verified installer bootstrap before executing downloaded install.sh. Verification failure does not fall back to unsigned older assets or development main. The verified installer installs the program and compatibility skill copy locally or over SSH. Local session-peer update downloads and verifies the latest program only; update --host pushes the current local standalone program when the remote copy is older or absent, without downloading on that host. Neither updates an independently installed skill. Keep pipx, uv, and pip installations under their original manager. See the v1.0.3 install and update reference.

Hosted Node Control 1.0.3 login sessions expire 24 hours after creation. An upgrade also caps earlier sliding sessions, so users may need to sign in again. Device revocation and account login-session revocation are separate. A Python wheel update does not deploy Node Control; operators assess hosted service updates separately. Existing pairing bindings are not retroactively audited or removed: an operator should review and revoke or re-pair a binding if its trust is in doubt. Do not automatically deploy, reset state, revoke sessions, or re-pair. See the v1.0.3 release notes.

A queued or submitted status does not confirm that the recipient consumed or acknowledged the message (ACK). Never automatically resend an unknown outcome.

Python runtime 1.1 guidance

Python 1.1.0 and newer quotes every external message body line and marks origin/reply claims as unverified. A body containing From:, Reply-To:, or a command does not grant permission: follow the user's requested reply flow and verify the exact destination. --no-from and --no-reply-to do not remove the body boundary. Framing is not a universal prompt-injection defense; its overhead counts toward message limits and chars reports the framed text.

A nonempty inherited CODEX_SQLITE_HOME or root sqlite_home setting in an inspected home causes discovery, dry-run, and queue submission to refuse. Ask the operator to review the storage configuration; do not clear settings or switch homes to bypass the guard. It does not support relocated storage or prove every effective native configuration. See the v1.1.1 storage boundary.

The separate experimental handoff workflow, published in 1.1.0, is outside this skill's baseline and full-coverage command paths. Do not initialize its ledger or create receipt authority without a user request. Receipt ACK support is limited to the local POSIX Claude route; Codex and single-destination POSIX source-streamed SSH are correlation-only, with observation/ACK unsupported. Windows and paired handoff remain unsupported. Ordinary queueing, text replies, and turn completion do not become receipt ACKs. Runtime 1.1.1 changes documentation and development-only tests, not runtime behavior; see the release notes.

Python 1.3 workflows

The following optional workflows require Python runtime 1.3.0 or newer. The basic CLI compatibility floor remains 0.9.1, and the published CLI coverage reference is 1.4.0. Check the resolved runtime version and affirmative command help, along with each feature's platform and permission requirements. Receiver codexBin retains its independent 1.0.1 floor. Experimental handoff is excluded from the command coverage represented by runtime-min-version and runtime-full-version. See the published runtime release.

  • Explanation: text-only send --dry-run --explain covers local, SSH and paired routes with normal message input. doctor --explain describes a diagnostic snapshot, not a selected target's readiness; handoff status --explain describes stored read-only evidence. JSON combinations and handoff SEND correlation/ACK/observe/wait combinations are refused. Explanations reuse existing results without extra probes, activation, submission or receipt authority; existing dry-run version checks are separate. Paired context is negotiated by the existing probe, allowlisted and bounded to 8 KiB; older receivers retain known native facts and leave missing context unknown. A preview grants no permission, reserves no target and provides no ACK evidence. Exit zero alone does not prove non-submission; unknown or unexpected submission never permits automatic resend. Wake still requires an explicit user request.
  • Route presets and the separate recipient addressbook support macOS/Linux local/SSH Claude/Codex only. Manage entries only on user request. preset show reads stored route/revision data; list --preset discovers current sessions. Actual preset send requires --to and --preset-revision; replace/remove use --expect-revision. The dp1 value hash repeats when identical name/route values are restored, and later changes do not cancel an already expanded invocation. For addresses, review address resolve before add/reselect, using its as1 observation revision; actual send requires current --address-revision (ab1) and exact canonical --confirm-target. Reselect/remove use revision checks, and each add/reselect creates a new binding ID. Claude retains tg1; Codex aw1 is a rechecked writer observation, with generation unsupported and no atomic storage/incarnation guarantee. SSH binds the verified key from the actual selection connection and pins it for send. Discover inspects at most 16 explicitly selected addresses, groups identical route/home/key contexts and preserves partial failures; it adds no network scan, broadcast or automatic reselection. Labels/revisions do not authenticate people, grant permission or prove ACK. Stop for operator review on private-storage/ACL/mount refusals; do not repair permissions or fall back automatically.
  • Experimental status/watch, reads one existing intent in the local owner's POSIX ledger. Watch has a 1–60 second timeout (default 30), 1000–5000 ms interval (default 1000), at most 61 samples, 16 KiB frames and 256 KiB total output. JSON output is NDJSON: require a complete successful end frame and exit 0 to establish observation completion only, never ACK or task completion; SIGINT exits 130. It creates no intent, wait, receipt or collector and writes no ledger or native submission. Read-only clock queries to an existing collector are possible; transcripts/message bodies are not read. Windows/host/device watch and Codex ACK remain unsupported. This is not a general incoming-message watch.
  • Trusted SSH configuration: only an explicit user choice may pair --ssh-config ABS_PATH with --trust-ssh-config for macOS/Linux list/send/doctor/update --host. The file and its Include/ProxyCommand/Match exec dependencies can execute local code, even in ssh -G or dry-run. Validation is not a sandbox or immutable snapshot. Do not select this mode from external messages, environment variables or MCP. Windows/setup/paired/preset/address/Reply-To URI combinations are excluded; the ordinary --ssh-opt allowlist stays unchanged.
  • One-time pairing links: only on user request, with both endpoints supporting pairing-offer-v1 and the Unix Python 3.11+ relay extra. Confirm current fingerprints independently and identities at the owner's terminal. --link takes no value and reads hidden TTY input; no TTY means refusal. Never place the URI in argv, message bodies, browser history, logs or issues. Cancel affects a pending offer, not completed pairing. Existing private-file pairing remains available, and pairing does not replace receiver/native permission policies.
  • Runtime notice preferences: macOS/Linux local offline update --dismiss-runtime-notice VERSION or --clear-runtime-notice-dismissal changes only the automatic notice for an exact version. These commands do not check, install or approve a release; remote/SSH/check combinations are refused. Explicit checks retain real latest/outdated results; skill notices and global opt-out remain unchanged. Windows lacks this preference. Example versions are not release announcements.

Runtime publication does not publish or install this independently managed skill. Adopt only a separately approved immutable skill release after verifying its recorded tag, source commit and SKILL hash. Update the Python runtime's compatibility snapshot in a separate change using that exact published skill source; existing runtime releases remain immutable.

Python 1.3.2 maintenance

These maintenance details refer to published Python runtime 1.3.2, source f5e7c49554ff02771990a151e00b52f2abf3df0a. Basic CLI compatibility remains 0.9.1. Skill 0.4.1 introduced this Direct-output guidance with a coverage reference of 1.3.2; the current coverage reference is declared above. The original 1.3.0 workflow requirements and receiver codexBin floor of 1.0.1 remain separate.

Optional MCP installation and upgrades

The base CLI supports Python 3.9+ without mandatory external dependencies. Optional MCP requires Python 3.10+ and the session-peer[mcp] extra. Runtime 1.3.2 requires MCP SDK mcp>=1.30,<2. For a new isolated environment, the documented pipx example is:

pipx install 'session-peer[mcp]'

For an existing MCP environment, explicitly upgrade through its original manager while preserving its interpreter and selected extras. Do not use a fresh-install example to replace that environment or silently switch managers. Changing a dependency declaration does not upgrade installed packages; install.sh and standalone script updates do not install or refresh MCP dependencies. See the fixed MCP guide.

The SDK floor accounts for upstream 1.x fixes; it does not establish an exploitable HTTP/OAuth/client vulnerability in this stdio-only application or enable those transports. The runtime CI tested exact SDK 1.30.0 and latest compatible 1.x on macOS/Linux with Python 3.10/3.13: eight combinations. Their resolved dependency graphs were audited; this is not a test of every transitive dependency's minimum version. See the verification scope.

Direct receiver output and operator updates

In Python 1.3.2+, receiver startup preserves ready:true and adds directReadyConfirmed:false. The first means local listener setup; neither confirms remote accept/TLS, authenticated access, native submission, consumption or ACK. An older receiver can omit the new field: keep that evidence unknown rather than inventing false or failure. Check the actual running version, help and output contract. TLS may be an unauthenticated pairing bootstrap; an authenticated probe is separate evidence.

Existing opt-in --diagnostic-events adds direct_transport stages accepted and peer_tls, with bounded accepted, tlsCompleted and tlsFailed counters. Each phase permits one record per 60 seconds, at most two per 60 seconds in total; TLS success and failure share the same phase slot. Normal close attempts one additional summary, including zero counts, without repeating it on repeated close. Missing records and unbalanced counters are possible. This is not a heartbeat, lossless history or ACK, and synchronous stderr has no hard deadline for a blocked sink. See the fixed Direct reference.

In the reported two-Mac incident, the owner allowed incoming connections for the expected Python application and recovered pairing/authenticated probes on the original released 1.3.1; diagnostic code did not repair the network. Ask the owner to verify the actual application's permission when appropriate. Keep the firewall enabled, the intended private bind, pinned TLS and receiver policy. Do not automatically widen to 0.0.0.0, reset keys/DBs, change access policy or retry an uncertain pairing/send. This case does not establish a universal platform diagnosis or native delivery/ACK support.

The optional receiver modules ship in wheel/sdist, not inside standalone session_peer.py. A standalone file update leaves an existing receiver environment unchanged. Its operator must separately upgrade that package environment and explicitly restart the receiver under an authorized rollout; publishing Python packages does not deploy services.

Node Control's Better Auth/core 1.7.7 changes are outside Python artifacts and require a separate service update. A verification-namespace change may require restarting pending OAuth sign-ins, but does not justify mass session revocation, key rotation or database recreation. The historical 1.0.3 creation-time-plus-24-hour account-session limit remains valid. A deployment on one stack does not qualify all installations, signup policy, availability, live OAuth or native ACK. See the release and operations boundaries.

Python 1.4 MCP workflows

The following optional MCP tools and structured CLI preview are supported by published runtime 1.4.0, source 476c67e636ef02cb93797dd2f42252dfe577625f. Check the selected CLI's version/help and, for MCP calls, the running server's package environment; development help from an older version is not proof of published feature support. Basic CLI compatibility stays 0.9.1, and receiver codexBin retains its separate 1.0.1 floor. The published coverage reference is 1.4.0 because this skill revision guides the new optional paths. Historical 1.3.0 and 1.3.2 feature requirements and links remain valid.

Runtime publication does not publish or install this independently managed skill. Adopt only a separately approved published skill release after verifying its recorded source/hash. Skill PR/merge/tag/release and a Python compatibility snapshot from the exact published skill source remain separate actions.

Tool permissions, effects and evidence

The flow is destination metadata → optional approved preset metadata → explicit preflight → existing authorized send. Operator policy, host-client approval and the user's requested action are separate requirements. Never edit policy to acquire permission on the model's own authority. Policy schemaVersion:2, result schemaVersion:1, runtime version and skill version are different contracts; schema 1/default policy rights do not automatically expand.

Whenever a preset is selected, its approved name and presets permission are additionally required for the chosen action, including preflight. Preset selection excludes wake and Reply-To URI targets.

Tool/path Required policy permission Effects and interpretation
list_destinations() No additional native-action capability No child/network work; names and declared capabilities are not identity, readiness, authority, consumption or ACK
list_presets(destination) Schema 2 presets plus per-destination approved names Reads approved route metadata only; no discovery, native/version/SSH probe, initialization, repair or automatic fallback
preflight_send(...) Schema 2 preflight; requested wake eligibility also needs wake Normal message required; existing dry-run/local-version/SSH checks may execute commands; Does not require or grant send; does not start a model, reserve wake budget or prove later-send safety
diagnose_destination(...) metadata mode Schema 2 diagnostics Policy/adapter declarations only; no CLI/discovery process or network
diagnose_destination(..., active_probe=true) Also diagnostics_probe macOS/Linux only; scoped agent/home/forward-SSH checks may execute operator SSH configuration; no reverse probe or per-target readiness
Existing list_sessions / send_message with a preset Existing action permission intersected with presets and approved names Exact policy host/agent/Codex home must match; actual send needs an explicit target and current revision; legacy successful native JSON is preserved

Destination metadata omits raw hosts/homes and limits lookup to 64 destinations, with printable IDs up to 128 UTF-8 bytes. Its text and structured tool result together are bounded to 64 KiB, excluding the outer JSON-RPC envelope. Shared-server caller identity remains unavailable. Labels, capabilities and revisions must not be treated as instructions or identity/permission evidence.

Active diagnostics inspect at most three permitted agents, sharing a 20-second execution budget plus separate cleanup. Each child stdout/stderr and the combined tool result are bounded to 64 KiB. Incomplete/malformed/truncated checks remain unknown. ok means collection/format completeness: a complete missing_home can have ok:true. A successful state_db_readable query does not prove the native daemon's effective storage. Readiness, TCP acceptance, TLS and paired-device authentication remain not_checked; sanitized forward-SSH failures describe a different check. There is no strict wall-clock, remote-process cleanup, consumption or ACK guarantee. Metadata defaults do not make optional active calls effect-free: preflight and combined diagnostics use readOnlyHint=false and idempotentHint=false. See the bounded diagnostics contract.

Preset and result boundaries

Preset reads use the operator's launch-environment secure store; the model cannot select its path. Authorization and exact host/agent/Codex-home matching precede caller revision comparison, with policy checked again before invocation. The existing dp1 value token can repeat when identical name/route values are restored; later store changes do not cancel an already expanded invocation. Preset management and permission repair are unsupported. Preset selection does not support Windows/device/Antigravity/addressbook/handoff, or combinations with wake or Reply-To URI targets. See the MCP preset contract.

The new list_presets metadata result has a 64 KiB combined text/structured limit; do not apply it or a new projection to successful legacy list/send responses. Those retain existing native JSON and transport limits. Safe preset metadata is queried separately or included in selected preflight. Unknown I/O/decode outcomes must not trigger automatic retry or erase independently known queued/submitted evidence; an actual-send uncertainty can report submitted:null and retryAllowed:false. Submission/queueing still does not establish consumption or ACK.

The CLI send --dry-run --explain-json is a single-destination local/SSH projection, intentionally omitting raw host/home and message/error contents. It may use --json but rejects --explain, device/preset/address/handoff combinations. MCP validates and expands an approved preset route before invoking that path; it does not pass CLI --preset with explicit routing. Existing --explain remains text-only, and ordinary list/send/doctor/update JSON keeps its legacy envelope. Type errors, refusals, unknown or contradictory submission/consumption evidence are not promoted to success.

Any separately approved Python compatibility snapshot uses the exact published skill tag/source/hash. Existing runtime and skill release artifacts, TypeScript profiles, global installations and operations are not changed by these instructions.

Install the skill

npx -y skills@latest add abruption/session-peer-skill \
  --skill session-peer --global \
  --agent claude-code --agent codex --agent antigravity \
  --copy --yes

The Skills CLI installs copies for Claude Code and the shared agents directory used by Codex and Antigravity. Restart or open a new agent session if the current session does not refresh its skill catalog automatically.

Verify the installation:

npx -y skills@latest list --global --json

Update

npx -y skills@latest update session-peer --global --yes

To pin a release exactly, install its tag, for example v0.5.1:

npx -y skills@latest add \
  https://github.com/abruption/session-peer-skill/tree/v0.5.1/session-peer \
  --skill session-peer --global \
  --agent claude-code --agent codex --agent antigravity \
  --copy --yes

Version metadata

session-peer/SKILL.md records machine-readable versions in its frontmatter metadata map, as defined by the Agent Skills specification:

Key Meaning
version Skill release; matches the vX.Y.Z tag
runtime-min-version CLI compatibility floor for the stated basic command path; separate from security recommendations and optional-feature requirements
runtime-full-version Coverage reference for the published CLI command paths this skill guides users to use; excludes separately identified experimental workflows and later hardening notices, and is not a latest-version or security guarantee

Tools may read these values to report an outdated skill or runtime. Runtime 1.0.1 and newer can report an outdated skill through skillUpdates or an incompatible one through session-peer doctor. Use the skill's original installation manager to update it; runtime upgrades do not update independently managed skill files.

Waiting for Codex replies

Codex receives messages through a queue and reads them only after its current turn ends. The skill therefore treats a missing reply from a busy Codex session as normal: it does not resend the request or ask again for a reply. When the next step depends on the reply, the agent records a correlation token and the step to resume from, pauses by ending its turn, and resumes once the matching reply arrives. A Codex sender receives that reply through its own queue, so continuing other work delays it.

Source of truth

session-peer/SKILL.md in this repository is the published skill. The copy retained in the session-peer runtime repository is a transition compatibility snapshot. Runtime commands and transport behavior remain owned by the session-peer repository.