Files
PaperClipAI/packages/shared/src/runtime-exposure/loopback-bind.ts
T
bd059a073d fix(workspaces): make managed runtimes reliable across restarts (#11740)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work
> - Execution workspaces need isolated databases, ports, and runtime
services
> - Concurrent workspaces could reuse ports or lose service ownership
after a restart
> - A markerless worktree also needed seed recovery, but normal
markerless instances still needed to boot
> - This pull request makes seed, port, and service ownership state
explicit and recoverable
> - It also checks live process and listener identity before it reclaims
shared resources
> - The benefit is reliable workspace startup, restart, adoption, and
concurrent provisioning

## Linked Issues or Issue Description

**What happened?**

Managed workspaces could lose runtime service ownership after a
control-plane restart. Concurrent worktrees could also reuse a port when
their parent paths differed. A seed recovery change made every
markerless instance resolve a worktree seed source, so normal instances
without a source could not start.

**Expected behavior**

Paperclip must preserve healthy managed services across restarts. It
must reserve unique ports across worktree parents. It must provision a
registered markerless worktree, but it must skip seed work for a normal
markerless instance.

**Steps to reproduce**

1. Start two managed worktrees under different parent paths at the same
time.
2. Restart the control plane while a managed service stays alive.
3. Start Paperclip with a config that has no seed markers and no
registered worktree source.
4. Observe duplicate port selection, lost service adoption, or a
seed-source startup error.

**Paperclip version or commit**

Current `master` plus the workspace runtime reliability changes in this
pull request.

**Deployment mode**

Local development with managed execution workspaces and embedded
Postgres.

## What Changed

- Added a shared port registry with lease heartbeats, process identity
checks, and live listener probes.
- Reserved worktree ports across custom parent paths and repaired
duplicate legacy assignments.
- Preserved and adopted healthy managed services across control-plane
restarts.
- Reconciled guest bind modes and verified listener ownership before
termination or reuse.
- Provisioned registered markerless worktree databases and kept normal
markerless instance startup as a no-op.
- Added CLI, shared, server, and shell regression tests for seed, port,
listener, restart, and adoption behavior.
- Updated the worktree development documentation.

## Verification

- `pnpm exec vitest run cli/src/__tests__/worktree.test.ts
--reporter=verbose` — 63 tests passed.
- `pnpm exec vitest run
packages/shared/src/worktree-port-registry.test.ts --reporter=verbose` —
5 tests passed.
- Focused runtime Vitest set — 199 tests passed across 37 suites.
- `node --test scripts/__tests__/provision-worktree-self-heal.test.mjs`
— 10 tests passed.
- `git diff --check` passed.

## Risks

- Port reservation now depends on lease and process identity data. The
fallback listener probe prevents early reclamation when process metadata
is incomplete.
- Runtime adoption is stricter about bind and owner identity. The tests
cover healthy adoption, stale records, PID reuse, and unrelated
listeners.
- Markerless seed detection now separates registered worktrees from
normal instances. The tests cover both paths.
- There are no database schema migrations.

> For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and
discuss it in `#dev` before opening the PR. Feature PRs that overlap
with planned core work may need to be redirected — check the roadmap
first. See `CONTRIBUTING.md`.

## Model Used

- OpenAI Codex with the `gpt-5` model family. The serving snapshot and
context-window size are not exposed. The agent used reasoning,
repository tools, code execution, and test execution.

## Checklist

- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have searched GitHub for duplicate or related PRs and linked
them above
- [x] I have either (a) linked existing issues with `Fixes: #` / `Closes
#` / `Refs #` OR (b) described the issue in-PR following the relevant
issue template
- [x] I have not referenced internal/instance-local Paperclip issues or
links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip`
URLs)
- [x] My branch name describes the change (e.g. `docs/...`, `fix/...`)
and contains no internal Paperclip ticket id or instance-derived details
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] All Paperclip CI gates are green
- [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups
- [x] I will address all Greptile and reviewer comments before
requesting merge

---------

Co-authored-by: Paperclip <noreply@paperclip.ing>
Co-authored-by: Dev Agent <dev@paperclip.ing>
2026-08-19 14:55:16 -05:00

99 lines
4.4 KiB
TypeScript

/**
* Forcing a managed runtime's listeners onto loopback through argv (PAP-17256).
*
* The broker only exposes a port whose listener /proc proves to be loopback-only,
* so an exposed Paperclip dev runtime MUST bind `127.0.0.1`. The server used to
* request that with env vars alone (`PAPERCLIP_BIND` / `PAPERCLIP_BIND_HOST`),
* which is not sufficient: the process that has to honour them is the *guest
* checkout's* `scripts/dev-runner.ts`, and a checkout that predates managed
* exposure overwrites `PAPERCLIP_BIND` from its own `--bind` argv and deletes
* `PAPERCLIP_BIND_HOST` outright. A branch pinned at such a commit therefore
* bound `0.0.0.0` and every expose was correctly denied with
* `listener_ownership_mismatch`.
*
* argv is the one channel every dev-runner version honours, because each of them
* derives its bind mode from `--bind` / `--bind-host` *before* writing the child
* env. Rewriting the command is what actually makes the loopback bind binding.
*
* Pure string functions only — no I/O, no process state.
*/
/** The only bind preset an exposed managed runtime may use. */
export const RUNTIME_EXPOSURE_BIND_MODE = "loopback";
export const RUNTIME_EXPOSURE_BIND_HOST = "127.0.0.1";
/**
* `--bind <mode>` / `--bind-host <host>`, in both the space- and `=`-separated
* spellings. Each takes exactly one value, and a value is never another flag.
*/
const BIND_SELECTING_ARG =
/(?:^|\s)--bind(?:-host)?(?:=|\s+)(?!--)[^\s]+/g;
/** Legacy aliases for `--bind lan`; they select a non-loopback bind. */
const LEGACY_LAN_ALIASES = /(?:^|\s)--(?:tailscale-auth|authenticated-private)(?=\s|$)/g;
/** True when the command carries an explicit bind selection of any kind. */
export function commandSelectsBindMode(command: string): boolean {
return new RegExp(BIND_SELECTING_ARG.source).test(command)
|| new RegExp(LEGACY_LAN_ALIASES.source).test(command);
}
/**
* A Paperclip dev-runner invocation — the only shape that understands
* `--bind` / `--bind-host`.
*
* Deliberately keyed on the *command*, not the service name. `--bind` means
* something entirely different to an unrelated process (the HTTPS probe canaries
* pass it to `python3 -m http.server`), and appending flags a command does not
* parse turns a working service into one that exits on startup.
*/
const PAPERCLIP_DEV_RUNNER_COMMAND =
/(?:^|[\s;&|])(?:(?:pnpm|npm|yarn|bun)(?:\s+run)?\s+dev(?::once|:watch|:server)?(?=\s|$)|[^\s]*dev-runner(?:\.[cm]?[jt]s)?(?=\s|$))/;
export function isPaperclipDevRunnerCommand(command: string): boolean {
return PAPERCLIP_DEV_RUNNER_COMMAND.test(command);
}
/**
* Rewrite a Paperclip dev-runner command so it explicitly requests the loopback
* bind, replacing whatever bind selection it carried.
*
* A command that is not a dev-runner invocation is returned untouched — see
* {@link isPaperclipDevRunnerCommand} for why that guard is not optional.
*
* The legacy `--tailscale-auth` / `--authenticated-private` aliases are
* deliberately *left in place*: an explicit `--bind` already wins over them in
* every dev-runner version, they still correctly select the authenticated
* deployment mode an exposed lane wants, and `isPaperclipDevRuntimeService`
* matches on `--tailscale-auth` as a substring, so stripping it would silently
* change readiness handling.
*/
export function forceLoopbackBindInCommand(command: string): string {
if (!isPaperclipDevRunnerCommand(command)) return command;
const stripped = command.replace(BIND_SELECTING_ARG, "").trim();
if (stripped.length === 0) return command;
return `${stripped} --bind ${RUNTIME_EXPOSURE_BIND_MODE}`;
}
/**
* Point a probe URL at loopback, keeping its scheme, port, and path.
*
* An exposed runtime's listener is loopback-only by construction, so probing it
* on any other host cannot work. The live config happens to declare a loopback
* readiness URL, but the fallback target is the service's display URL — a
* MagicDNS name like `http://paperclip-dev:42003` — which only ever answered
* because the guest was wrongly bound to the wildcard. Normalising here keeps
* the loopback fix from turning that latent mismatch into a readiness timeout.
*/
export function rewriteUrlHostToLoopback(url: string | null): string | null {
if (!url) return url;
try {
const parsed = new URL(url);
parsed.hostname = RUNTIME_EXPOSURE_BIND_HOST;
return parsed.toString();
} catch {
// Not a URL we can reason about; leave it for the caller's own handling.
return url;
}
}