shipper auto-ship enable

shipper auto-ship enable

Usage: shipper auto-ship enable

Request Auto-ship and register this checkout for supervision

Arguments

Argument	Required	Description	Choices
None	-	-	-

Flags

Long	Short	Value	Default	Description	Choices
None	-	-	-	-	-

Examples

Request Auto-ship for the current repository and register this checkout.

shipper auto-ship enable

Exit Codes

Code	When
0	Checkout registration and the durable desired-state update succeed.
1	Repository identity, registry, or desired-state storage fails.

Constraints

• Successful registration and intent recording do not confirm pickup. Enable reports Pickup unconfirmed and asks for status after roughly five seconds; it never starts or contacts a supervisor.
• Acts only on the current checkout; there is no repository argument, all-repositories mode, worker-count flag, or command-specific option.
• This is durable runtime state, not Shipper configuration, and it does not read or edit settings.
• Before enabling, the command adds, updates, or leaves unchanged the resolved local checkout in the retained shared sources.mcp registry partition. A new identity starts with Auto-merge off; an existing identity keeps its recorded choice. Output names the recorded checkout path and, when an update repoints supervision, the path it replaced. The checkout becomes supervisable and visible to Desktop and the daemon as a repository Shipper manages on this machine.
• Terminal enable and MCP enable apply exactly the same durable desired-state semantics: enablement is requested, an outstanding repository halt is preserved, and only a genuine not-enabled-to-enabled transition clears an engaged safety stop and advances its accounting generation.
• The provisioning asymmetry is limited to the supervisor: MCP enable additionally makes a bounded attempt to provide a supervisor, while terminal enable starts and contacts no supervisor. Dispatch can begin only after Desktop or the daemon observes the record.
• Repeated enable leaves an engaged safety stop unchanged and names shipper auto-ship resume; output separately reports registration added, updated, or already present, enablement changed or unchanged, whether a repository halt was preserved, and the atomic safety-stop outcome.
• Enable never clears a repository halt. A halted repository that is enabled remains non-dispatching until shipper auto-ship clear-halt releases the hold.
• Every Auto-ship record mutation first classifies the retained bytes under the shared lock. A future schema is retained unchanged and refused with its path and a request to reconnect with a current Shipper client or re-run the Shipper installation. A valid record for another canonical repository is retained unchanged and refused with both identities and a request to resolve the file outside Shipper. Neither conflict has a Shipper repair, reset, or discard gesture, and refusal output makes no dispatch-holder or mutation-success claim. Corrupt replaceable records can still be recreated, versions 1 and 2 migrate losslessly to version 3, and successful output reports core applied/unchanged outcomes plus any migration.
• Checkout registration happens before the record mutation. If registration was added or updated and the record is then refused, output reports only that completed registry fact before the refusal; already-present registration is disclosed too. Any later intent-write failure retains and reports successful registration; no rollback or compensating disable occurs. Registration failure means enablement did not complete and leaves the prior enabled setting exactly unchanged. Unreadable registry information is preserved unchanged; use a build able to read it, restore a damaged file from a valid copy, or correct the reported access/lock problem.
• The command records local durable intent and returns immediately. Enabled means requested, not running. When a supervisor observes enabled and unhalted, it retracts unconsumed repository-control checkpoint Stops while preserving explicit per-run Pause and Stop gestures; the command reports no retraction count or observed runtime outcome. A running supervisor normally observes an external write within roughly five seconds.
• Only a strictly proven alive dispatch holder is named by established surface, PID, and acquisition time. Its presence proves neither observation of the write nor remaining in-flight work; all other evidence is reported unavailable.