Portable Forge Rescue

Applies to CLI 0.17.5 with Windows/Linux x64 Rescue 0.16.3. See releases.

Rescue is an attended temporary access path. A person on the target runs the Windows executable with elevation or the Linux package with root authority. It does not install the persistent Daemon unless you explicitly promote the session.

Prerequisites

Install the complete signed technician package and sign in to the intended workspace.
Run forge rescue doctor to check the workstation and Rescue readiness.
Rescue creation requires a protected capsule-signing identity that matches the identity trusted by the signed Rescue payload. A normal login alone does not provision that matching identity.

If the preflight reports an issuer mismatch or capsule_issuer_not_ready, ask your Forge administrator/support contact for the approved matching Rescue configuration. Generating a new unrelated key does not make an existing signed payload trust it. Do not use unsigned-pilot bypasses for customer work.

Create and deliver

forge rescue session create --label "Example temporary target" --platform win-x64 --out rescue-package

For a Linux target, use --platform linux-x64. Windows is the default when the option is omitted. Creation returns a local session code, readiness information and delivery location. Keep the code and bootstrap package private.

The Windows executable's generated filename carries the bootstrap capability; do not rename it. Deliver the Linux folder intact, including its manifest, signature and private rescue.code, and follow its generated README.txt. Never paste the file's contents into a command, public ticket or chat.

Current sessions have a bounded one-hour lifetime. Prepare a fresh session for a new attended visit rather than treating Rescue as permanent access.

Observe and connect

Shared links (source-only continuation)

The following commands require a compatible CLI build and Bridge with explicitly provisioned shared Rescue issuance; they are not part of the signed 0.17.5 release. Unlike local package creation, sharing uses Bridge's existing verified download and signing service. The CLI generates and retains its own SSH private key in the selected profile. No server private key is downloaded, no existing control lease is adopted, and creation alone does not connect to the customer.

Save a private JSON request before dispatch:

{
  "idempotency_key": "customer-visit-unique-key",
  "label": "Example temporary target",
  "platform": "win-x64"
}

Use linux-x64 for Linux. Optional fields are expires_at (absolute UTC time, within 60 minutes), case_id and contact_id. The default is 30 minutes. Case and contact IDs record requested context, not verified customer identity or completed device relationships.

forge rescue share create --input request.json
forge rescue share status --code <returned-session-code>
forge rescue share link --code <returned-session-code>
forge rescue session connect --code <returned-session-code>
forge rescue share revoke --code <returned-session-code>

Creation returns the usable customer URL, platform-specific instructions, expiry, share ID and local session code directly in authorized JSON. URLs may be used in authorized agent responses and customer drafts, but never operational logs or public tickets. Windows customers keep the exact downloaded executable filename and approve elevation; Linux customers follow the verified TAR's instructions and enter the code only at its private prompt.

If creation's response is lost, retain the profile and private session directory. Repeat the unchanged input, or use forge rescue share create --code <code> to resume the exact persisted request, absolute expiry and original key. Do not generate a replacement request key. An incompatible Bridge is refused before issuance; server-owned-key fallback is not supported. Missing local keys require restoring the original state or revoking the exact share, not adopting another client's connection.

Status and revoke also accept --share <UUID> without local connection state. Link redelivery requires the originating CLI session. Revocation stops authority and removes that session's local key but does not claim remote cleanup. Use the ordinary session close flow for acknowledged remote cleanup while authorized. After connection, the existing SSH/SCP, explicit diagnostics and promotion paths below use the same owned key and native relay.

forge rescue session list
forge rescue session status --code <session-code>
forge rescue session connect --code <session-code>

<session-code> is the local code returned by creation, not the customer bootstrap filename or a temporary-history UUID. Use the same local profile that created the session.

Once the target is ready, connect returns an SSH alias. Use the exact returned alias for authorized shell and file operations:

ssh <returned-alias> hostname
scp local-file.txt <returned-alias>:<remote-file-path>

Commands run elevated, as with enrolled access. Confirm the machine and agreed scope first. For explicit diagnostics on a connected Rescue target:

forge diagnostics collect --rescue-code <session-code> --sections identity,storage --output rescue-snapshot.json

See diagnostics for selection, sensitivity and cleanup rules.

Close and verify

forge rescue session close --code <session-code>

Read the returned cleanup result. Closing a local connection is not the same as proving that remote temporary state was removed. If cleanup is unconfirmed, preserve the recovery information and follow the returned next actions while authorized; do not delete local state just to hide the warning.

Rescue history is separate from enrolled inventory. Browser/API visibility of a temporary record is read-only and does not transfer control to another technician. Owner-bound access and expiry still apply.

Promote only with explicit permission

If the customer has agreed to persistent unattended access:

forge rescue session enroll --code <session-code> --label "Example enrolled target"

The promotion uses a one-use enrollment bound to the Rescue session. It waits for authenticated permanent-Daemon health before closing Rescue. If the outcome is uncertain, inspect the session and permanent device rather than assuming consumption means a healthy installation.

Promotion history preserves the original temporary period and a separately authorized permanent-device link; it does not rewrite temporary events as enrolled-device history.

Repair Live USB is a separate boundary

The repair USB work provides bounded local assembly of SystemRescue and verified Linux Rescue. It is not a publicly distributed modified ISO, a Secure Boot support promise or a general Windows recovery guarantee. Diagnostics from a live environment describe the running live OS, not an offline installed system. Do not infer broader recovery capability from ordinary Linux Rescue support.

Table of Contents