Files
PaperClipAI/maps/feature-map/runs-adapters.md
T
Devin FoleyandPaperclip c5ca29dbef fix(claude): prepare compatible sandbox runtimes during onboarding (#17259)
## Thinking Path

> - Paperclip connects agent accounts and prepares their execution
environments.
> - A managed sandbox image can outlive the model defaults shipped by
the app.
> - Claude setup skipped installation whenever a CLI was already on
PATH.
> - The selected model then failed its minimum-version check after
sign-in succeeded.
> - This pull request prepares a compatible private CLI before testing
or running it.
> - Cloud onboarding also stops asking customers to run inaccessible
shell commands.

## Linked Issues or Issue Description

**What happened?**

A new managed Cloud stack completed Claude subscription sign-in. Its
environment test then failed because the snapshot contained Claude Code
2.1.263, while the selected `claude-opus-5-5` model requires 2.1.280.
The screen displayed Manual debug commands that a hosted customer cannot
run.

**Expected behavior**

Paperclip prepares its managed runtime before testing the selected
account. A stale image CLI does not require the customer to upgrade a
server package. Failed preparation still blocks hiring. Cloud does not
display manual shell debugging.

**Steps to reproduce**

1. Start a managed sandbox with Claude Code 2.1.263 on PATH.
2. Connect a Claude subscription and select `claude-opus-5-5` on the CLI
lane.
3. Connect the agent. Installation is skipped because the command
exists, then the version gate blocks the hello test.

**Paperclip version or commit**

Source baseline: `6204239cfc8c3be79fc185cf3f468ebaa0ab1e3e`.

**Deployment mode**

Authenticated managed Cloud with a Daytona named snapshot. The
correction also applies to the default CLI in other managed sandbox
transports.

Related work: Refs #14993 sets model/runtime requirements; Refs #15993
changes native defaults on qualified targets. Neither prepares an
outdated default sandbox CLI on this path. Searches found no open
duplicate.

## What Changed

- Check the actual default CLI against the selected model's existing
minimum version.
- When a sandbox's default command is outdated, install the exact
required npm package into a private versioned workspace prefix. Reuse a
compatible private installation. Keep the image's global CLI intact.
- Verify the private executable and use that same command for the
account hello test and normal CLI runs, with matching command metadata.
Probe effort support after preparing that executable so the chosen
effort is retained. Keep the model, account, engine and permissions
unchanged.
- Return safe preparation checks to environment tests and normal run
logs, distinguishing installation failure causes without returning raw
installer output or credential-bearing URLs.
- Exclude provider and Paperclip credentials from the installer
environment. Preserve the existing failing version gate if installation
or verification cannot succeed. Local, SSH and explicit custom commands
remain operator-managed.
- Hide Manual debug and legacy operator check hints on Cloud and while
deployment metadata is unknown; preserve check messages and details.
Retain self-hosted help and the detailed failed checks. Cloud copy asks
for a retry instead of asking the customer to repair the environment.
- Add subprocess-backed runtime controls, an account-probe regression
and mounted Cloud/self-hosted wizard controls. Update development
guidance and the affected capability maps.

## Verification

- Passed all Claude source suites and the server Claude execution suite
on head `c941ae44c22d8dafec0df033a129e39ce4ebd966`: **412 passed**, one
existing opt-in test skipped. These include the new command/effort
ordering, safe installer diagnostics, environment forwarding and run-log
regressions.
- On final head `0ecae0e9304f495a57524158b3700b8e9bc21cb8`, passed **208
tests** across all 174 mounted onboarding wizard tests and 34 Claude
execution tests. The failure fixture includes the real command-bearing
hint, and execution asserts both metadata command fields agree.
- Passed `pnpm -r typecheck`, `pnpm build`, `pnpm check:token-gates`,
`node scripts/check-maps.mjs` and `git diff --check`. Full typecheck and
build were repeated successfully on final head
`0ecae0e9304f495a57524158b3700b8e9bc21cb8`. [Latest-head
CI](https://github.com/paperclipai/paperclip/actions/runs/39879208694)
is green: 54 checks passed and two skipped, including browser E2E and
serialized database suites.
- The new runtime controls execute real subprocesses with a controlled
installer. They cover an old CLI, an already compatible CLI, failed or
ineffective installation, local/custom commands, and an unknown version.
The probe regression asserts that the hello call uses the private
executable.
- A separate non-root local subprocess check installed the real npm
`@anthropic-ai/claude-code@2.1.280` package. Its private command
reported 2.1.280, the simulated image CLI remained 2.1.263, and a second
preparation reused the private copy. This ran on macOS ARM64. It did not
use a provider account, send a model prompt, or prove live Daytona
behavior.
- Attempted `pnpm test:run`. Embedded PostgreSQL initialization failed
after five attempts on this Mac with `Postgres init script exited with
code null`. The unchanged native-session database cases then failed.
Stopped only that full-suite process tree after recording the repeated
startup failure. No full local-suite pass is claimed; Linux CI must
cover those tests.
- The first new subprocess fixture had a quoting syntax error. It was
corrected before the passing focused runs. The one-off real-package
script first required an ESM extension correction, then passed. Logs
retain both attempts. A new execution assertion initially inspected the
final sandbox cleanup shell instead of the launched command; it now
checks execution metadata. A broader directory selection also picked up
generated `dist` tests whose Markdown fixtures are not copied by the
build (two ENOENT failures). The explicit source-suite run above passes;
no generated-test pass is claimed.
- Apex review: **5/5**, reviewed final head
`0ecae0e9304f495a57524158b3700b8e9bc21cb8`, all five earlier findings
addressed and resolved, no new findings.
- Merge, deployment and a fresh live Cloud subscription test are still
required. No customer account or production runtime was changed by this
branch.

## Risks

- An outdated sandbox needs npm registry access and up to 120 seconds
for one bounded installation attempt. A failed or unverified install
continues to block execution.
- The versioned package uses sandbox workspace storage. Compatible
cached copies avoid repeat installation within that workspace. Existing
runtime cleanup and sandbox lifecycle still apply.
- The compatible version comes from the adapter's existing model-version
contract. This does not add a model fallback or change the selected
execution engine.
- No schema, credential, permission, workflow or lockfile change.

## Model Used

OpenAI Codex, based on GPT-6, assisted with implementation and
verification. The exact serving model ID and context-window limit are
not exposed in this session. Capabilities used: code editing, shell
execution, API inspection 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>
2026-10-22 18:44:53 -07:00

13 KiB
Raw Blame History

navigation
navigation
section sectionOrder order
Agents and reusable capabilities 30 20

Runs, harnesses, and model accounts

Operators choose an agent harness and model account, inspect execution history and transcripts, and distinguish a working configuration from a successful task result.

Feature ID: runs-adapters.

Implementation: adapter manager, run host, configuration.

Agent access: companion.

Sub-features

  • availability: runs-adapters/availability — discover installed adapters and available models/accounts.
  • validation: runs-adapters/validation — test an adapter in the selected execution environment and surface authentication failures.
  • runs: runs-adapters/runs — inspect run status, events, output, costs, and the source task.
  • session: runs-adapters/session — preserve or reset execution context through supported lifecycle actions.

How to get to it (user POV)

adapter-setup

Open an agent’s model/adapter configuration or the instance adapter settings page when permitted.

run-history

Open an agent run at /agents/:agentId/runs/:runId from the agent or task activity. The agent header has one Run now action. Administrators can enable Capture raw provider traces under the agent configuration’s Debugging section for future runs. The header shows Raw tracing on while that setting is enabled.

For latency diagnosis with an operator OTLP endpoint, search the hashed run ID without restricting the root span name. Compare workspace preparation with its workspace_<step> intervals. Measure controller readiness separately through controller.startup.<phase>. A recovery pause or deployment drain is not model execution time. See the tracing contract. These source-level diagnostics do not establish a live response-time budget. Inspect native.controller.<phase> for backend construction, assigned-tool discovery and post-turn cleanup. Compare those intervals with the actual model turn; do not count a nested discovery interval twice.

Driving it with Playwright and the Paperclip CLI

Preconditions: follow the baseline. Record adapter, model, account, native/legacy runtime, and environment. Capabilities vary; one harness result is not a matrix-wide qualification.

adapter-setup

Automated: adapter validation routes and model refresh cover server behavior.

Claude native setup uses the existing Anthropic API-key or subscription connection flow. Record the selected account separately from successful execution; unavailable models/authentication and unsupported Legacy-only options must fail visibly.

Claude CLI tests and runs also prepare a compatible private executable when a managed sandbox image's default CLI is too old for the selected model. Verify the command used for the hello test and task, reuse of a compatible private installation, and a blocking failure when installation cannot establish a valid version. Local, SSH and explicit custom commands retain operator management. Cloud onboarding must not offer shell commands the customer cannot run.

Manual: Select the intended adapter and account, refresh model choices, and run its environment test. Save, reload, then execute a small task. Repeat with a deliberately unavailable account and verify the failure remains visible.

For Legacy Codex, assign a service secret such as SLACK_BOT_TOKEN through agent configuration and run a task that checks its presence without printing its value. Check both ACP and CLI execution. Remove the binding and repeat on the next run. The assigned secret must reach shell tools; an unassigned host token and Codex's own login keys must remain unavailable. Verify the same delivery without an agent identity. Shell-policy metadata must contain names rather than values.

Choose Codex as the harness; the UI displays its name/icon for both runners. Advanced identifies the automatic default and offers Paperclip Runner or Legacy. New Codex agents default to the native runner on supported macOS or GNU/Linux targets; the shared selection contract and runtime prerequisites define the platform/libc boundary. Windows and Alpine/musl remain Legacy. Claude follows its qualified rollout described above. Disabled adapters, external overrides, and selected-target qualification also affect availability.

Choose OpenCode with the native-runner experimental flag off on a qualified macOS or GNU/Linux x64 target. Linux ARM64 must retain Legacy because its pinned OpenCode runtime is not qualified. Advanced should show Paperclip Runner as the automatic default on qualified targets. Save an inactive draft without a model, resume it, select an explicit provider/model, test, finish setup, and reload. Verify the saved provider is opencode. Repeat with explicit Legacy and an existing Legacy agent; neither should migrate on an unrelated edit. Check that saved native permission/lifecycle choices survive resuming setup. Custom commands, arguments, variants, and inherited permissions must give Legacy remediation when native is selected. A live task with the selected account is separate proof from these setup and persistence controls. Repeat with Pi on macOS or GNU/Linux x64 after explicit operator setup of the pinned runtime (paperclipai runtime setup pi). Linux ARM64 retains Legacy. Resume an inactive model-free draft, connect an account, choose a provider/model, and finish setup with the generic native flag off. Verify Pi branding and native ACPX Pi execution by completing a simple assigned task. Preserve saved native thinking/permission/lifecycle settings on resume and unrelated edits. Native thinking supports off, low, high, max; legacy aliases must give remediation, and returning to Legacy must reject settings it cannot honor. On a fresh forced-Kubernetes instance without an environment row, inspect discovery and create with automatic selection. Both must retain Legacy without provisioning; an explicit Paperclip request must give target-qualification guidance. Begin the ordinary task to exercise the existing lazy environment path. This live journey remains separate from the resolver's source controls.

For sandbox defaults, follow the environment probe recipe first. Discovery/creation read company-bound immutable-image evidence without allocating a target. A mutable image or snapshot name does not establish native compatibility. Then test the actual selected runtime with its selected account/model: a legacy CLI or authentication probe alone cannot establish native readiness. For an image-provided Codex harness, verify both final executables after concurrent artifact preparation on an eligible provider. Repeat with a failed runner probe and confirm the harness work has settled before failure returns. Providers without concurrent sync and explicit harness installs remain serial. The real-shell artifact controls cover these source contracts; they do not establish live reply latency. For remote native Codex with managed GitHub access, inspect the controller preparation spans for overlapping GitHub setup and assigned MCP discovery. Provider startup must wait for both. Force either preparation to fail while the other is pending; confirm that the pending operation settles and run-owned access is released before failure returns. Repeat a warm follow-up and retain its actual reply time. The executor controls cover ordering, failure drain and credential projection; they do not qualify a live response-time target. Missing dependencies, failed authentication, invalid models and incompatible custom settings must remain actionable errors without silent runner switching. Saved unchanged execution can still be tested without applying new selection policy, but runtime/account validation must still run.

Verify an automatic Codex hire and an explicit Legacy control through a useful file artifact, follow-up and reload. Preserve Codex reasoning effort and account isolation; retain explicit Legacy permission choices, including false. Reopen an existing agent, make an unrelated edit, and confirm both its persisted runner and next run stay unchanged. Use hiring/import preservation for approval and portability controls.

Test native Codex with a saved subscription whose setup auth file is a managed link, as well as a regular file and an API-key account. Setup must seed the isolated probe from the checked account without exposing credentials or changing its saved runner. With subscription authentication, an unbound configured CODEX_HOME with linked credentials must fail setup with managed-account or explicit Legacy guidance; it must not claim readiness when task isolation would omit the file. Dangling or incorrectly owned credentials must also fail clearly. A selected CODEX_API_KEY or OPENAI_API_KEY takes precedence over an unrelated subscription file. Test valid, dangling and invalid subscription links with that selected key; setup must test the key without reading or refreshing the unrelated account. The private probe copy must be removed after confirmed retirement following success, failure or cancellation. Unconfirmed shutdown remains a cleanup failure. Exercise an unavailable local daemon and a preparation failure before probe handoff. No owned temporary credential copy may remain, and original account files must be unchanged. A probe whose shutdown is unconfirmed must retain its recovery state; do not treat it as a preparation-only failure. Existing setup controls use fake credentials; real account execution remains a separate acceptance requirement.

run-history

Automated: live run routes and run event sequencing cover run data contracts.

Manual: Start a disposable task, open its running transcript, and follow it to a terminal outcome. Reload and compare task/run IDs, status, output, and cost. Verify a failed run remains distinguishable from a completed run with useful output.

An explicit runner change starts a configuration revision and invalidates the eligible session. Active runs, restart recovery and historical transcript parsing retain their recorded execution configuration; do not infer their runner from a later edit to the agent. Account/harness branding and execution identity are different observations, both required in the evidence.

For an onboarding child-completion callback, verify actual session/turn events and the source-correlated reply. A succeeded row alone is insufficient: the literal ea6c8eb5e16d61111968f633a66748b397b64a3e managed attempt was marked successful during startup without a provider turn. The recovery correction preserves the existing validated Done-parent handoff; process-death and ownership checks remain active. Its PostgreSQL controls are separate from the required revised-source live onboarding and follow-up proof.

Gotchas

  • Model accounts are managed in Apps and inline agent account controls. /company/settings/connections configures decision/fast-response models, not the general model-account library.

  • The run log is instance database data; it is not the opt-out first-party Telemetry system or operator-configured OpenTelemetry tracing.

  • Authentication/model discovery does not establish tool, image, steering, or resumption capability parity.

  • Use recovery for interrupted runs and execution environments for local/SSH/sandbox differences.

Native setup retirement joins owned startup before cleanup can be confirmed. Transport ownership controls hold preparation or registration without launching a provider, then check bounded close, rejected duplicate requests, no later launch and retention of unconfirmed state. Readiness observes shutdown; resumed startup cannot reactivate ingress after close. These are lifecycle controls, separate from installed provider proof. The real daemon readiness and recovery controls require their existing native fixtures in hosted CI; passing credential-free controls does not qualify them. A primary setup timeout remains a failure even when teardown also fails.

For remote setup shutdown, verify that each durable-state read respects the remaining suspension deadline. A late result cannot establish suspension or queue a replacement command after that deadline. An intentional ingress close must observe physical socket closure before retiring its connection owner and releasing the endpoint; an unresponsive peer must not extend the setup budget. The existing transport and ingress suites exercise these conditions without a provider. Repeat the actual managed setup and useful task journey separately; the literal 651a3de64fc943216cc414b64b1443809f9499da Test attempt failed cleanup before hire and retains its unconfirmed recovery state.