Devin FoleyandPaperclip
c7f4b74111
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Each task must have an isolated workspace that its agent can read. > - Older project checkouts can contain worktrees for restricted tasks. > - The source access check correctly rejects these shared checkouts. > - A fresh task then fails even when its agent can clone the project remote. > - This pull request gives fresh default tasks a separate clone of the same remote. > - The task can start while the restricted task files remain protected. ## Linked Issues or Issue Description **What happened?** Fresh tasks fail with `Task workspace access is no longer available` when their default project checkout contains a restricted task worktree. The caller has access to the new task and its remote repository. The shared local Git source is unsafe to copy. **Expected behavior** Use a separate clone of the same authorized remote for a fresh default task. Keep source access checks and responsible-user Git credentials in force. **Steps to reproduce** 1. Put a restricted task worktree inside a project checkout. 2. Assign a new default task to an agent that cannot read the restricted task. 3. Start the new task. The current source check fails before workspace creation. 4. With this fix, the task uses a separate remote source. The restricted files are absent. Later runs reuse the same owned source. Related work: Refs #15749, Refs #15528. This change keeps their source retention and workspace ownership checks. ## What Changed - Add a remote source path scoped to the company and task. - Clone through the run’s Git connection after the shared source fails its access check. - Reject reused workspaces, explicit selections, pinned branches, local sources, credential-bearing URLs, and symlink paths. - Check source access again before publishing the workspace. - Resolve later runs from the verified recorded source. Ignore leftover clones that the saved workspace does not own. - Record provenance for new implicit Git defaults. Read the current task binding before fallback. Preserve explicit, inherited and ambiguous legacy checkout choices. - Keep the effective task strategy during startup validation of matching implicit defaults. Preserve the existing explicit-selection write check. - Add regression coverage and document the fallback. ## Verification - Merged master `c8efdbfba43` and resolved both rounds of catalog/index conflicts. All upstream suites, classifications, source references and story IDs are preserved. Both fix branches combine cleanly in either merge order, with no catalog fingerprint drift. - Passed locally: 313 focused source-isolation, preparation, task-creation, binding and trust tests before the final startup fix. The final fix passes all 100 source-trust, task-binding and environment-selection tests. Earlier workspace-resolution and persisted-source suites also passed. - Real-Git regressions cover all three review findings. Reconstruction ignores an unrecorded clone and preserves unpublished commits/files. Explicit and parent-inherited checkout IDs without typed selections retain their denial and branch tips without cloning or acquiring an environment. A protected-project heartbeat completes and resumes using the task’s Git strategy with read access. Explicit selection still requires writes, and a mismatched default is rejected. - Passed: the complete Storybook catalog check with no drift errors, feature and agent map structure checks, and all 17 catalog/index script tests. The generated index counts match the merged catalog. The current upstream verification-route inventory remains unchanged. The catalog contains all 262 authored suites and 2,481 story IDs. - Passed: full workspace typecheck and build after the final guard changes, on latest head `79d2adadcb6d3d7a04b9943a91bdb8b0b6abea6d`. - Latest head `79d2adadcb6d3d7a04b9943a91bdb8b0b6abea6d`: complete CI passed (54 successful checks, two intentional skips), including the full general/serialized suites and all eight browser shards. Fresh Greptile Apex review is 5/5 on this same commit, with no unresolved findings or recommendations. The full local test command was attempted earlier without a complete aggregate result; the complete suite result is from CI. - Manual check: configure a shared project checkout with a restricted task worktree. Admit a fresh default task using the authorized remote. Confirm separate Git storage and no restricted local branch or file. Reuse, close and reopen the task workspace. Confirm that explicit, literal branch and low-trust selections retain the denied source. ## Risks - A clean remote clone excludes unpublished local work. The fallback applies only to fresh default tasks and rejects existing workspace or branch selections. - A private remote can fail to clone when the responsible user lacks Git credentials. The run then reports the failure; access checks are not bypassed. - Older untyped checkout bindings cannot prove default provenance. They keep the source denial instead of silently dropping unpublished work. - New implicit Git defaults use the existing workspace-intent contract. The source directory uses existing instance storage. No schema migration is required. ## Model Used OpenAI GPT-6, model ID `gpt-6`, through Codex. Used reasoning, repository inspection, code editing, terminal tools, and test execution. The API session does not expose an exact context window size. ## 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>
7.7 KiB
Execution workspaces, services, and files
A project or task can use a managed workspace with inspectable files, Git state, services, and runtime controls. Operators can follow its lifecycle through provisioning, use, and closure.
Implementation: workspace list, execution workspace, project workspace.
Agent access: companion.
Sub-features
binding: identify the workspace actually bound to a task/run.provisioning: observe readiness and failures instead of inferring readiness from a created record.services: start/stop supported services and inspect logs and exposed endpoints.files-git: inspect workspace files and repository state used for the deliverable.closure: close/reopen or reconcile through permitted controls without losing work.
How to get to it (user POV)
task-workspace
Use the task’s workspace card or Files panel and follow its workspace link.
workspace-management
Open /workspaces, a project workspace, or /execution-workspaces/:workspaceId and its Services/Configuration/Runtime logs views.
Driving it with Playwright and the Paperclip CLI
Preconditions: follow the baseline. Enable isolated-workspace UI where needed. Use an owned disposable repository and environment; record workspace ID and branch.
task-workspace
Automated: workspace card and task binding cover host/binding contracts.
Manual: Run a task that writes a small file, follow the bound workspace, and inspect the file and revision. Reload and verify links still refer to the same workspace, not another checkout or a stale run.
For fresh standard-trust tasks using an implicit repository default, create a disposable project checkout whose shared Git storage overlaps a private task workspace. Verify that source admission creates a separate checkout from the configured remote, with no private local branches, commits or shared Git storage. Reusing, closing and reopening that task must retain the company/task-bound source; a failed workspace save must clean up only its owned checkout. Explicit workspace, parent/channel selections, literal or task-independent branch templates, low-trust tasks, and local or credential-bearing remote URLs must not use this fallback. A selected checkout requires recorded default provenance. Create tasks through the task service with an explicit checkout ID or an inherited parent source but no typed selection; verify denial, no clone or environment acquisition, and preservation of unpublished branch commits. Older ambiguous bindings and source choices changed during preparation must retain the denial. The remote-source tests and preparation tests exercise the real Git isolation and lifecycle guards. They do not qualify live remote credentials or a provider deployment.
For task workspace selection, use the authorized task workspace API to choose a task directory, project source, or existing workspace. Verify that a change made during a run stays pending until the next normal admission. Submit another choice using the returned revision, then retry the superseded request; it must fail without replacing the newer pending choice. A projectless task must retain its files across resume and reassignment. Use the repository preparation API to add an authorized repository beneath that workspace; repeat the request and verify that it reuses the checkout and pinned revision. See task binding tests and repository access tests. An existing projectless folder alias of a sandbox-restricted project must be rejected for a standard local task before its adapter executes. Repeat after relocating the configured source; retained ownership must still enforce the boundary. This is separate from ordinary authorized file preview/download. For a registered worktree selected for a sandbox or SSH environment, configured and built-in provision scripts must not run on the controller during fresh creation, reuse, or rebuild, including host runtime provisioning. Repeat with standard trust and a protected read-only source, then with source write grants; permissions must not change execution placement. Verify isolated source copying and selected-environment dispatch still work. Repeat an explicit local isolated source choice: copying remains available but controller scripts must stay absent, including after binding or metadata changes and closed-worktree reopening. An implicit trusted local project default remains a positive provisioning control. Repeat with a newer configured default overriding an older primary source, then with a newer primary overriding an older nonprimary source. Both configured and built-in hooks must run for the implicit local default. Task creation and controller classification share configured-default, primary, creation-time and ID precedence. Explicit choices and saved copy-only markers still suppress hooks; changing the default must not rotate an existing binding or clear its marker. SSH keeps its explicit remote provision-command path; these checks do not claim a new sandbox provision transport. Low-trust closed-worktree reopening, including a board-comment reopen of a projectless task, must also suppress both kinds of host provision script. Returned checkpoints must reject file, symlink or missing parents before host writes, even if a nested file is marked unchanged. The retained host file and recovery evidence must survive rejection. These are automated safety contracts, not new live runtime acceptance.
For a child created by an admitted agent with an explicit existing workspace, verify that a matching sandbox boundary permits creation before the child has an ID. A changed child policy, unrelated parent, or forged creator run must fail. See the child workspace trust regression. This automated contract does not add live acceptance evidence.
workspace-management
Automated: workspace detail and runtime service cover UI and runtime contracts separately.
Manual: Provision a disposable workspace, wait for readiness, start an available service, open its endpoint, and inspect a real response and logs. Stop it and verify it actually stops. Exercise close/reopen only after inspecting pending changes and active runs.
Gotchas
-
UI visibility, default isolation policy, the local environment row, a workspace record, and a running service are distinct prerequisites. A fresh instance still needs an owned cwd/repository and runtime commands;
/workspaceslists existing work. Reopening depends on lifecycle, not a generic detail action. -
A link or running badge does not prove the service is reachable from the user’s browser.
-
Workspace IDs, runtime leases, and repository paths are not interchangeable.
-
Organizational project, source project, task files, personal
AGENT_HOME, and provider home have separate meanings. Private source ownership remains attached to copied files after source configuration changes or workspace closure. -
Use recovery for divergence/export repair and CLI operations for local worktree tooling.