Ship keeps the shared Teploy navigation, typography and colors. The run page organizes each task into Conversation, Review, Changes, Verification, Files and Activity. Review keeps the conversation and composer beside the evidence; live updates preserve typed drafts.
In the Inbox, choose a connected project and describe what you need in everyday language. Make a change, Ask a question, Make a plan, and Review work state the expected result. Questions, plans and reviews use scan mode; Ship does not publish changes for those tasks. A plan is a deliverable you can then discuss or turn into a separate change request. This differs from the native harness's optional approval pause before implementation.
Editors can Send for approval without execution authority. These requests stay proposed even on an automatic project; an authorized teammate must approve and start them. Recent requests link to the launched task. Viewers can follow work but cannot submit requests. The project supplies the environment, agent, permissions and budget; teammates do not enter infrastructure settings.
Starter workflows include updating wording, understanding a feature and exploring an idea. Drafts are retained in the current browser tab. Task pages summarize what needs attention, fold execution metadata and older messages, and keep the follow-up composer outside the scrolling history.
- Open Projects → Project setup. Register the repository, choose an image or inherit the worker default, and specify tests or leave detection enabled. New projects propose incoming work and require a person to authorize merges. Registering an existing repository preserves its settings.
- Read the setup checks. A configured image is not proof it can start; a successful storage ping is not proof Git credentials or model access work. Use the linked read-only review to verify the worker's execution path.
- Choose a workflow from the Inbox or Projects. Built-in templates cover bug fixes, features, repository reviews, tests and dependency updates. People with the policies grant can create, edit and delete shared templates.
- Review the prefilled instructions and repository, then launch. Workflow selection itself does not execute anything. Reviews use scan mode.
- Open the run. Conversation shows recorded progress, delivered instructions, questions and decisions. New messages to a steerable run arrive at its next checkpoint; the pending indicator distinguishes queued from delivered.
- Review Changes and Verification. Activity retains detailed command output and the recorded-step index.
- On a completed, failed or cancelled run, start a follow-up. Earlier requests and results remain in the conversation (up to 20 runs of context). Choose the existing PR or current default branch. The worker checks PR state before launch, then checks again at checkout; a closed or merged PR requires the default-branch choice. This starts a fresh sandbox, with bounded conversation context and the PR branch’s code, not a resumed terminal or browser session.
- While a PR task page is open, Ship requests worker refreshes at most every 30 seconds (60 seconds after errors). Refresh from forge also reads the PR’s current head, reviews, commit statuses and GitHub check runs through the worker. The timestamp is explicit. A changed head warns that this run’s recorded verification belongs to an older commit. These reads never grant merge authority or substitute for verification gates.
- Files reads tracked file names and committed content at the available sandbox’s HEAD. It is a bounded inspector, not an editor. Expired sandboxes report unavailability; uncommitted changes remain in recorded diff snapshots.
Project setup can save a repeatable preparation command and timeout (up to 15 minutes). Every newly enqueued run records this configuration and runs it inside the sandbox after checkout and before the agent. A failed command stops execution with a recorded outcome. The same setup applies to additional attempts. Existing runs keep their recorded configuration and step fingerprints.
Verify environment launches a deterministic check through the worker's normal authorization and admission path. It clones the repository, runs saved preparation and test commands, records the actual results, then releases the sandbox. It makes no model calls and publishes no changes. Missing or failing tests cannot produce a successful verification. Use a separate review request when you want an agent to investigate a failure.
The setup-only behavior is recorded in new run inputs. Older environment checks keep their original agent-backed behavior, and an older worker holds new checks rather than accidentally running them as paid scans. Preparation commands may install dependencies or start services, but Ship does not automatically provision arbitrary databases or secrets.
Workflows supports hourly, daily and weekly schedules. Schedules copy the selected template’s instructions; later template edits do not alter them. Occurrences enter the Inbox through the normal deduplicated intake path. Source/project policies decide whether they remain proposed or auto-launch, with existing budgets, admission and auto windows. Read-only and plan-review modes survive both manual and automatic launch. Pause/resume and recent scheduled work are visible in the UI. Downtime coalesces missed intervals into one current occurrence instead of a catch-up burst. This is interval scheduling, not cron or a dependency-graph automation builder.
New published runs record a bounded diff snapshot inside the existing
repo-push result, alongside its commit SHA. No workflow step was added.
Older runs may have only intermediate critic/attempt snapshots, or none.
Snapshots retain their step name and time; the forge remains authoritative for
subsequent PR changes. Large snapshots are partial and marked accordingly.
While a run is parked at a decision — a question, a plan, an approval — an operator with steer authority can take exclusive writable ownership of its sandbox from the run page. Writes are fenced at the sandbox daemon: while the lease is held, nothing else can exec or write in that workspace, and a decision delivered mid-takeover makes the run wait for handback instead of racing the human. The run page shows who holds a workspace and until when.
While you hold a workspace, the takeover card becomes a panel with five tabs.
Console runs one submitted command at a time under the lease and streams its output as it arrives (the page polls; there is no persistent connection). It is a console, not a terminal: no interactive stdin, no TTY emulation — a program that asks a question gets no answer. Commands are capped at 2,000 characters and two minutes; output is bounded to its tail and redacted. The project's declared tests command keeps its own button. Every command is recorded in the session and named to the resumed agent.
Editor opens one text file at a time from the changed-files list or a typed path. Reads are bounded (200,000 characters — the same cap as writes, so what opens can save), binary files are refused, and paths outside the work tree are rejected. Saving replaces the whole file — the same fenced write as before, uncommitted. There is no syntax highlighting and no partial-edit application. The editor guards unsaved changes when you switch files or hand back.
Browser drives a real headless Chromium running inside the sandbox — the
same one the visual and flow rungs use (the node and go sandbox images ship
Debian Chromium plus a pinned Playwright; the rust image does not, and the
tab says so honestly instead of failing opaquely). It is screenshot-driven,
not video and not a live stream: every navigate, click, typed text, key,
scroll or viewport change re-loads the page at the recorded URL and returns
one bounded image (about 300 KB; JPEG when a PNG would exceed the cap), which
the page renders at natural size so click coordinates are viewport
coordinates. One driver process per action, under the lease's fenced exec:
continuity comes from an ephemeral profile (cookies, storage) that is
excluded from the repository, wiped on close and handback, and never persists
across sessions — no credential storage, by design. The URL bar accepts
http(s) only (a /path resolves against the current page); file:, about:,
data: and browser-internal pages are refused with a reason. The browser
reaches exactly what the sandbox's network tier allows: on a none network
it can only reach services inside the sandbox, which is precisely the
app-under-test case — the point of the tab is clicking through the app the
agent built before approving the merge. DOM state does not survive between
actions (each action re-loads the page); URL, cookie and storage state do.
Every action renews the lease and is recorded in the session like a console
command. A lapsed lease cannot close the driver — the profile is left to the
container's own teardown and the session note says so.
Changes shows the working-tree diff against HEAD and refreshes after each save. Handback records the session — files written, commands run, a digest of the diff, the holder's note — and leaves the resumed run a message describing the edits, so the agent commits the human's work rather than building over invisible changes.
Every operation renews the lease; an abandoned one expires on its own (default
30 min, SHIP_TAKEOVER_TTL_SEC) and is recorded as lapsed, with edits on disk
preserved — re-acquire to continue.
Boundaries, on purpose: a run reviewing a merge cannot be taken over (edits there cannot join an already-published PR — request changes instead) and an executing run must be steered or parked first. The console runs commands as the workspace user inside the sandbox; it is not a shell session and keeps no environment between commands. Reconnect after lease expiry beyond re-acquiring remains future work, as does browser DOM state between actions.
Verification is derived from recorded outcomes, never an agent's assertion that tests passed. Missing checks say not recorded. The page includes test output, preview/PR links, screenshot attachments and short browser recordings.
A .ship/flow.mjs script may record WebM files into its output directory.
Ship collects up to two recordings smaller than 4 MiB each, hashes them and
stores them for authenticated review. Playwright needs its video encoder in the
sandbox; the example prompt falls back to screenshots in older images.
The worker stores PNG/WebM artifacts independently of the forge, keyed by
SHA-256. File deployments use the state directory; Nucleus deployments use a
separate chunked table with integrity-checked reads. Authenticated Ship routes
serve images and video byte ranges. Set SHIP_PUBLIC_URL for usable artifact
links in PR bodies; otherwise links are relative within Ship. If storage fails,
the Forgejo attachment path remains a fallback. No artifact retention deletion
is automatic in this version. Capture still requires a working encoder in the
sandbox; browser-flow success is distinct from video delivery.
Account settings affect the current person; project overrides affect a repository; deployment defaults configure the worker. Existing runs retain materialized inputs. Connections offers bounded health checks against installed service addresses, without forwarding credentials, following redirects or performing model inference. These checks test the dashboard's network path, not the worker's. Detailed deployment values remain read-only.
Checked against official product documentation on 2026-09-19. These are product patterns and documented capabilities, not measured claims about coding quality.
| Reference | Pattern applied in Ship | Remaining distinction |
|---|---|---|
| Devin session tools | Conversation beside organized changes, verification and execution history; linked follow-ups | Ship's takeover is worker-mediated (console, editor, screenshot-driven browser), not a direct remote session, and Ship does not embed a full IDE. |
| Devin playbooks | Shared editable workflows, review before launch | Templates support interval schedules through the existing intake policies; no general DAG builder. |
| Vorflux | Project preparation, plan review, visible PR evidence and browser recordings | Setup runs declared preparation commands and independent tests; arbitrary-stack provisioning still requires configuration. |
| OpenHands | Keep the conversation, recorded changes and review outcome together | No OpenHands engine is embedded; Ship retains its own durable execution and harnesses. |
| Sparkles | Simpler team task intake, reusable requests, visible progress and PR handoff | This does not add hosted infrastructure, a large connector marketplace, or new agent harnesses. |
Full IDE embedding, automatic merge reconciliation, arbitrary-stack environment provisioning, broader connector coverage and a controlled head-to-head coding evaluation remain distinct work. Live forge reads refresh while the task page is open; they do not automatically merge or rewrite recorded verification. No full product parity claim is made by this usability pass.
At merge review, requesting changes starts a linked run on the open PR and cancels the old pending merge decision without closing the PR. Read-only investigations leave that decision pending. Both require the existing approval and steering grants.
Plan approval currently requires the native harness. External adapters start work immediately; launches that explicitly request unsupported plan approval are rejected instead of silently skipping it. External scan prompts request findings and verification results, with no edited-tree deliverable.
A repeatable read-only production browser check is available as
scripts/workspace-browser-check.mjs. Provide SHIP_URL, SHIP_WEB_TOKEN and
SHIP_TEST_RUN, with Playwright installed (or PLAYWRIGHT_MODULE pointing to
its entry module). It checks eighteen desktop/tablet/mobile pages, hydration,
live JSON and unsent-draft retention without launching or approving runs.
Environment verification records a fingerprint of project setup. Project setup shows a verified receipt only when the matching run completed and independently recorded passing environment tests and preparation (when configured). Changing relevant project settings marks the receipt stale. This does not attest to later worker credential, image or service changes; re-run verification after those.
New runs check restored snapshots for a valid Git checkout before the agent continues, and check the origin for non-PR tasks. Fork PR identity remains the forge resolver's responsibility. This guards missing/wrong checkouts; it does not prove every uncommitted byte survived. Existing run inputs retain old behavior.
Projects currently use an owner/repository key with an explicit clone URL. Requests must match that URL's origin, protocol and port. Ship refuses a second forge's same-named repository instead of borrowing the first project's settings. Multiple same-named repositories across forges are not supported yet.
If a legacy project reports an identity conflict, open Projects using its owner/repository name and set its correct clone URL. Existing run histories remain readable and parked runs retain their recorded inputs. Do not delete a project to resolve a conflict without first checking its settings and references.
Team requests submitted for approval keep a request ID with the browser draft. A retry of unchanged content returns the original request, including one that was dismissed. Editing the draft creates a new request ID. Direct “Start task” and follow-up launch recovery are separate work; do not assume these have the same retry guarantee yet. File-store deployments support one server process; use Nucleus for a shared deployment.
See One task, proportionate workflow. Small changes still need scope, an approach and verification. Project settings can require the native plan-approval checkpoint for all new change tasks, including follow-ups and automations; a task cannot disable that requirement. Questions, plans and reviews remain read-only intentions. Existing runs retain their recorded checkpoints.
If starting a task loses its response, return to the Inbox and retry the saved draft. Its submission identity is retained, so the retry opens the original accepted run. Editing the draft starts a new request. Already completed runs are not restarted by retrying their submission.
An approved intake request that has not produced a visible run appears under “Starting or awaiting recovery”. An authorized teammate can retry its launch; Ship keeps the original run identity. The worker automatically finishes publication of durably accepted launches. A retry does not bypass project plan requirements, and pending/unknown acceptance is not represented as completion.
Follow-up messages also retain their request ID, task type, target and plan choice with the draft. Retrying an accepted follow-up returns its existing run; changing the request creates a new ID. Reusing an ID with different content is refused. Current launch authority is still required on every retry.
A change requested at merge review records its replacement intent durably. Ship holds that decision for the specific revision and records cancellation before scheduling the revision. The worker can resume this handoff after a crash. A competing merge/revision that already owns the decision prevents the child from starting; Ship reports that conflict instead of overriding it. Such conflicting accepted intents remain held for operator diagnosis; automatic reassignment or abandonment is not implemented. This is not an atomic transaction with the forge, and does not resolve ambiguous external push/merge outcomes.
The Inbox links to Launch recovery for people with current launch authority. This lists accepted direct, intake and follow-up launches that have not finished publication, including corrupt records and replacement-review parents. Pages are bounded to 100 entries with a cursor. Retry publishes the original accepted intent; it never creates a new task or overrides a competing review decision. Permanent conflicts remain held for investigation. Unknown external push, merge, deployment and notification outcomes still need their own reconciliation.
Files → Inspect live changes reads tracked edits against HEAD and untracked file names from the latest recorded workspace, including a restored handle. It does not read untracked contents or grant terminal/editor access. Output is bounded and redacted, with partial results labelled. It is an observation while the agent may still be writing, not a consistent checkpoint. Background PR reads no longer replace the displayed inspection. The recovery disclosure shows recorded snapshots/restores and repository validation without asserting that a snapshot still exists or that warm-volume edits are recoverable.
New pushed-change previews fetch the exact recorded commit into an isolated Git ref and worktree. Concurrent builds cannot overwrite FETCH_HEAD or remove one another's checkout. The preview slot includes a hash of branch and revision, so a later revision gets a different slot. Verification shows the recorded commit and image tag. An image tag is not an immutable image digest or a production release receipt. Preview slots expire under the configured CLI TTL.
Regression recovery removes that revision's preview; it cannot roll back the main app merely because a preview was deployed. Old recovery receipts without an immutable preview identity are held for inspection in the legacy rollback step. The production rollback helper requires an explicit retained version and never falls back to the mutable “previous” release.
Still required for production promotion: independently bind the repository and trusted deployment configuration to a destination; capture the exact artifact digest, deployed version and retained recovery version; bind an approval to those identities; reconcile uncertain CLI outcomes before retrying; verify the deployed revision and health, then demonstrate recovery on a scratch target. The UI does not yet offer production promotion or a writable workspace takeover.