Files
PaperClipAI/maps/feature-map/agents.md
T
DottaandPaperclip 87bf89756e fix: support Daytona runner upgrades and ignore obsolete Claude options (#17361)
## Thinking Path

> - Paperclip is the open source app people use to manage AI agents for
work.
> - Existing Claude and Codex agents can upgrade to Paperclip Runner.
> - A Daytona computer needs platform qualification before Runner
becomes its default.
> - The upgrade notice required that default, so it hid the action that
could start qualification.
> - Saved Claude turn limits also caused conversion to fail even though
Runner can run without them.
> - This pull request verifies the computer on click and ignores
obsolete Claude options with a warning.
> - Agents retain their model, account, environment, instructions, and
permission policy.

## Linked Issues or Issue Description

Related: #17122.

**What happened?**

A legacy Claude agent on a Daytona snapshot had no upgrade button until
its environment had platform qualification. A saved `maxTurnsPerRun:
1000` then caused conversion to return HTTP 422.

**Expected behavior**

The upgrade action verifies a supported Daytona computer and converts
the agent. Unsupported tuning options produce a visible warning and do
not block execution.

**Steps to reproduce**

1. Create a legacy Claude agent with `maxTurnsPerRun: 1000` on an active
Daytona snapshot.
2. Open Runtime before the environment has platform qualification.
3. Try to upgrade to Paperclip Runner.

**Paperclip version or commit**

After #17122, reproduced against `9c442cf48e`.

## What Changed

- Offer upgrade on probe-capable Daytona snapshots and immutable sandbox
images. Perform the public environment probe only after a click. Save
after fresh adapter discovery confirms support.
- Resolve the actual computer for explicit, instance-default, and hidden
managed environments. Preserve pending edits and reject stale probe
results.
- Ignore Claude `maxTurnsPerRun`, `chrome`, `warmHandleIdleMs`, and
`acpWarmHandleIdleMs`. Return structured warnings from create, hire, and
update. Show warnings in Runtime and after a save.
- Keep validation for commands, credentials, filesystem, network, and
permission settings.
- Retain the legacy turn limit in the existing live conversion fixture.
Update regression tests, upgrade stories, and capability maps.

## Verification

- Red: the old route returns HTTP 422 for the saved turn limit; the old
form hides the Daytona upgrade notice.
- Green: 417 focused server and form tests pass. A further 188 tests
pass after the review fixes. Qualification coverage includes failed
probes, unsupported targets, changed settings, managed defaults, unsaved
environment variables, and forced Kubernetes targets.
- `pnpm -r typecheck` and `pnpm build` pass. Token gates, map checks,
map tests, and Storybook catalog checks pass.
- Real local Claude Opus 5.5 conversion and task pass, with the
downloaded artifact checked against seeded source bytes, SHA-256, and
Git commit.
- Real browser upgrade and full Claude Opus 5.5 task on a disposable
named Daytona snapshot pass at `b81cec7d8c`. The saved agent retains its
model, high effort, credentials, timeout, and grace settings while
dropping the turn limit with a visible warning. Exactly one successful
run completed the task. The downloaded artifact matched independently
seeded source bytes, SHA-256, and Git commit; the source was unchanged,
no interactions remained pending, and the delivery link survived a
browser reload. The snapshot used current runtime assets built from
public source. The supplied Daytona account could not access the
original staging snapshot, so this verifies an equivalent local fixture
rather than that exact snapshot. Disposable test resources were cleaned
up.
- Earlier live attempts remain recorded: an image-based sandbox creation
failed, and the first named-snapshot probe returned failure with
unresolved provisional cleanup identity. Later named-snapshot probing
and the task succeeded; the initial creation failures are not attributed
to this PR or declared resolved. A separate attempt using the Oct 18
cached runtime failed the current provider-pack compatibility check;
rebuilding the runtime from matching public source removed that
mismatch. Owned resources were identified and cleaned up, with
diagnostic databases retained.
- 54 checks passed at `b81cec7d8c`, with no failed checks; Greptile and
Paperclip Review both scored 5/5, with both review threads resolved.
Master advanced during the live proof, so the branch was rebased with
both sides of additive import/test conflicts retained. On the rebased
head `2b74222b94`, 472 focused tests, UI typecheck, and UI build pass.
All required CI gates pass; Greptile and Paperclip Review both score 5/5
on this head, with no unresolved review threads. The PR is mergeable.
The serial local `pnpm test:run` was stopped after the CI test lanes
passed; that local run is not claimed as a pass.

## Risks

- An explicit upgrade can allocate a temporary probe sandbox and take
several minutes. Probe failures leave the agent on its existing runner.
- Ignored options no longer enforce a turn cap, Chrome integration, or
legacy idle-time tuning. The UI warns about each active ignored option.
- Unsafe or ambiguous execution settings still fail validation. This
change does not weaken environment qualification or runtime artifact
checks.

## Model Used

OpenAI Codex, GPT-6, with reasoning, code execution, and browser tools.
The exact deployment model ID and context-window size are not exposed in
this session.

## 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-24 07:59:18 -07:00

16 KiB
Raw Blame History

navigation
navigation
section sectionOrder order
Agents and reusable capabilities 30 10

Hiring, configuration, and organization

Operators hire agents, configure their identity and instructions, assign reporting relationships, and manage their lifecycle. Built-in agents have their own setup and lifecycle constraints.

Feature ID: agents.

Implementation: hiring, configuration, organization.

Agent access: companion.

Sub-features

  • hire: agents/hire — choose identity, harness, model, and required account settings; edit reporting relationships through the agent configuration afterward.
  • grok-bot: agents/grok-bot — experimental existing-Bot agent setup through remote OAuth, routine credentials, and an authenticated two-way challenge; current contact, stop and explicit recovery.
  • instructions: agents/instructions — edit agent configuration and instruction files with durable revisions.
  • organization: agents/organization — inspect and change reporting relationships through supported controls.
  • primary-agent: agents/primary-agent — choose a personal primary agent for the company, confirm replacement, and inspect its roster/sidebar and task/chat defaults.
  • lifecycle: agents/lifecycle — pause/resume or retire an agent while preserving history.
  • built-in: agents/built-in — configure required agents without treating them as ordinary removable hires.
  • api-keys: agents/api-keys — create and inspect named agent credentials, copy a new token once, and revoke it without changing agent identity.
  • managed-agent-setup: agents/managed-agent-setup — probe, create, or adopt a qualified Anthropic managed-agent profile with pinned provider resources and retention acknowledgement.

How to get to it (user POV)

hire-agent

Use New agent from the roster or /agents/new.

Submitting the name creates an inactive record before adapter selection or account setup. A name-only draft returns to adapter selection when reopened. Save & exit keeps its configuration; Finish setup on the agent returns to the same record. Final submission requests approval when required, then follows the existing preparation and verification lifecycle.

agent-configuration

Open /agents/:agentId and the configuration/instruction surfaces it exposes.

In /agents/all, select roster checkboxes and choose Edit connection & model. A mixed selection offers one action per harness. Each field is opt-in. The editor previews each changed value and excludes agents already at the target value. Models must be compatible with every selected connection. Failed writes show per-agent errors; Retry touches only the remaining agents. Connection pools and externally managed agents are not editable through this shortcut.

Verify connection-only, model-only, both fields, mixed-harness selection, hidden selections, no-op counts, incompatible models, partial failure and retry. Reload the roster and compare stored settings, including unrelated heartbeat and adapter fields. A concurrent configuration edit must return a conflict. Shared runtime validation, access checks, revisions and audit logging still apply. Live runs retain their existing settings; model changes can reset saved sessions. Connection adoption can require an explicit reset of existing sessions.

organization

Use the roster’s organization view; /org redirects to the roster in the streamlined shell.

personal-primary-agent

Open an agent profile and choose Set as my primary. Inspect its crown on the profile/roster and its position in the Agents sidebar, then open a new task or Chat.

agent-api-keys

Open /agents/:agentId/api-keys → API Keys with an authenticated person who can manage agents. The operator CLI also supports paperclipai token agent create -C <company-id> --agent <agent-id> --name <label>, token agent list -C <company-id> --agent <agent-id>, and token agent revoke <key-id> -C <company-id> --agent <agent-id>.

managed-agent-cli

Use the operator command paperclipai managed-agent setup --company-id <company-id> --profile-key <key> --display-name <name> --api-key-secret-id <company-secret-id> --acknowledge-retention --json. Supply ANTHROPIC_API_KEY through the process environment. Use --agent-id, --agent-version, and --environment-id to adopt resources, or --probe for provider reads without profile persistence. The optional session-list cost ceiling is --max-session-list-cost-usd.

Driving it with Playwright and the Paperclip CLI

Preconditions: follow the baseline. Use a disposable company and supported adapter; hiring may require a formal approval.

hire-agent

Automated: new agent page and configuration form cover mocked UI behavior.

Manual: Hire an agent with a distinct name and role. Complete any required approval, reload the roster, and open its configuration. Confirm manager, adapter, and model persisted; run a small task to prove execution readiness.

For a new Codex hire, choose the Codex harness. Automatic selection uses Paperclip Runner on a qualified selected target; Advanced offers an explicit Legacy runner override. Record the persisted runner and underlying harness, rather than treating the displayed Codex name as execution proof. See runtime selection and validation and target qualification.

Repeat with an explicit Legacy Codex hire. If approval is required, compare its reviewed execution configuration before and after restart and activation; approval must retain the reviewed runner. Test an existing Legacy and native agent through an unrelated edit, reload and restart: neither is automatically upgraded.

Creation defaults also apply to API/CLI hires, built-ins, plugins and new team imports. Exports preserve resolved execution choices; a package without a runner choice uses the new-agent default, while updating an existing same-harness agent preserves its execution. For a native Codex import, edit a model or account binding and verify unchanged runtime settings survive; an explicit clear must stay cleared. Use the portability recipe for package preparation and boundaries.

For Claude Code on qualified macOS or GNU/Linux x64/ARM64, submit without a runner override and inspect saved configuration: paperclip_runner, provider: acpx, acpxAgent: claude, and ordinary model claude-opus-5-5. The Advanced runner selector can explicitly choose Legacy. Keep explicit model/account choices and saved runners on edits. Verify useful output and a follow-up after a controller restart; setup success alone does not establish session continuity. Unsupported architectures/libc and unknown environment qualification retain Legacy. Darwin SSH also defaults to Legacy until automatic matching assets are qualified; explicit matching native assets and saved native configurations remain supported. Linux ARM64 cloud-image production remains deferred.

The current hiring wizard assigns the first hire CEO and subsequent hires General reporting to the CEO. Change manager/role afterward through supported configuration. Process/HTTP agents can be created through API/CLI but are excluded from the hiring picker; API fixture creation does not prove this UI journey.

agent-configuration

Automated: instruction service and instruction revisions cover file/revision contracts.

Manual: Save a harmless instruction edit, reload, and verify its revision and effect in the next eligible run. Pause and resume the disposable agent; confirm pause prevents new work and does not erase previous runs.

For failed setup, use an unavailable model or invalid command on a disposable agent. Confirm the profile names the failed verification step and gives a relevant action. Check that it explains automatic retry and offers Retry now. Fix the configuration, retry, and reload; the failure must disappear only after readiness commits. Provider output and credentials must not appear in the lifecycle message.

An explicit runner change is a configuration change, with normal revisions and session invalidation. Obsolete Claude tuning options (including maxTurnsPerRun) are ignored with a field-specific warning; permission, network, filesystem and command incompatibilities still produce an error. Selecting another runner must not silently discard security settings or change an active run's recorded execution. Keep runner choice in Advanced and verify the next eligible run separately from historical transcripts.

Existing legacy Claude and Codex agents on qualified default environments, or probe-capable Daytona snapshots / immutable sandbox images, show Upgrade runner above their configuration. Exercise that action with pending edits and an environment-variable draft; reopen the page and compare the saved harness, model, account bindings, instructions, and run policy. Check a saved maxTurnsPerRun: 1000: upgrade must warn and remove it. Test an initially unqualified Daytona Paperclip Computer: click must probe, record qualification, refresh availability, and only then save. A failed probe or changed selection must leave the agent on Legacy. Check a rejected permission setting, repair it, and retry. Verify a real task before and after migration, including its output, preserved history, and fresh session. The notice must stay absent for native agents, other harnesses, and unsupported targets. Discovery failure must not imply that an upgrade is available. Navigate to another agent while an upgrade is pending. Its result must stay with the original agent, without showing success on the new page or redirecting back. Focused coverage: save receipt and configuration form.

Storybook: Runner upgrade mounts the production page and shell with mutable HTTP fixtures for both harnesses, pending, failure/retry, incompatible settings, repair, native/unsupported states, and mobile/light presentation. Fixture success does not establish real migration or provider execution.

organization

Automated: org chart is component evidence. Built-in setup also has configuration modal tests.

Manual: Inspect a manager and report, change the relationship through the offered controls, and reload both views. Exercise a rejected invalid relationship. Configure a built-in agent and verify it retains its required identity and restrictions.

personal-primary-agent

Automated: primary-agent context and primary-agent routes cover selection, company/user scope, and request contracts.

Manual: Select an available agent, reload, and inspect the retained personal choice. Replace it and verify confirmation is required. Leave or terminate the selected agent through permitted controls and inspect the unavailable/cleared state. Switch company/user to check isolation. Open a task and Chat with a valid draft or recent selection; verify those explicit choices take precedence over the primary fallback. Opening Chat must not start execution.

agent-api-keys

Automated: CLI token tests mock create/list/revoke. Cross-tenant routes, agent permissions, and authentication middleware cover company/key ownership, management permission, responsible-user binding, and denial. They do not prove a browser-created key working against a live instance.

Manual: As an authenticated person with agents:create, create a named key for an eligible disposable agent and copy it privately from the once-only display. Make a harmless same-company agent request with that bearer, then reload the Keys tab and verify only metadata remains. Revoke the key through UI or CLI, reload, and retry the exact same bearer: authentication must fail. Inspect key-created/key-revoked activity without token values. Test a board person lacking agent-management permission, an agent caller, another company’s agent, a different agent’s key ID, and a pending-approval/terminated target. A created key without a real responsible-user binding is a failed acceptance prerequisite, not a working credential.

Sources: Keys tab, key routes, key service, authentication, and CLI token commands.

managed-agent-cli

Automated: Managed-agent CLI uses mocked provider/API responses. Profile route authorization and remote profiles cover actor/company checks and qualification. They do not establish provider provisioning or a useful managed task.

Manual: Start with known adopted provider IDs in an authorized disposable provider account. Run --probe and verify only provider reads: no resources are created and no Paperclip profile is written. Reject unsafe tools/network/package configuration, an unsupported model, duplicate profile matches, a missing retention acknowledgement, and a malformed secret UUID. During persistence, reject missing, inactive, or foreign-company secret references. Then create or adopt a locked profile in a disposable company; inspect its pinned version, model, environment, retention attestation, and cost ceiling through the profile API. Repeat setup and verify resource reuse. Reject viewer/agent writes and foreign-company references. Qualify useful task execution separately through the runtime recipe; a successful probe is not execution acceptance.

Sources: Managed-agent CLI, profile routes, profile service, and runtime validation.

Gotchas

  • Managed-agent probing is read-only at the provider and does not persist a Paperclip profile. The explicit retention acknowledgement remains required even for probe.

  • Agent keys, human CLI tokens, and personal assistant OAuth grants are different credentials. Never include a key’s plaintext token in screenshots, logs, or verification artifacts.

  • A roster entry is not proof of an authenticated or invokable adapter.

  • Pending hires may live in approval/task surfaces rather than the active roster.

  • Skill and tool grants are separate: see skills and app permissions.

  • A personal primary agent is a per-user/company preference. It does not change reporting lines, stars, permissions, or another person's primary agent.

connect-grok-bot

Choose Invite an external agent → Grok Bot, identify the Bot by its desktop name, connect its remote MCP plugin, configure a webhook-only routine, and verify delivery plus authenticated reply. Save & exit resumes the same agent. Keep pairing codes in browser authorization and routine credentials in Paperclip’s fields. A working Bot web URL is not required.

Prerequisites: authenticated public HTTPS, Assistant connections (MCP), Paperclip Runner and Grok Bot experimental settings. Cloud uses its normal managed Runner environment. Provider usage is unknown. Routine uncertainty blocks new assignments until explicit inspection and recovery; stopping work revokes Paperclip authority without confirming remote termination.

Evidence: source implementation and focused protocol tests; real provider assigned/proactive workflows and deployed managed acceptance remain release gates.

Documentation scope: Agents, organization, and runtime setup

Per-harness/model/account capabilities, every instruction-file error, and complete built-in-agent lifecycle variants remain separate qualification matrices.