mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-23 17:33:51 +02:00
DottaandPaperclip
042051904d
## Thinking Path > - Paperclip lets operators assign tools and credentials to agents. > - Legacy Codex starts provider processes and builds a separate shell environment policy. > - Both ACP and CLI removed every variable whose name contained KEY, SECRET, or TOKEN. > - This also removed service credentials that the operator explicitly assigned, such as SLACK_BOT_TOKEN. > - This pull request uses the resolved configuration to admit assigned service secrets by name. > - Every Codex launch keeps a bounded shell allowlist, including launches without an agent identity. > - Assigned scripts can use their credentials without adding unassigned host secrets to shell tools. ## Linked Issues or Issue Description Related: #16255. That PR fixes project-level exclude patterns. This PR fixes the removal of explicitly assigned service secrets and the fallback to an inherited policy when no agent identity is present. **What happened?** A Codex task could not run a Slack posting script. SLACK_BOT_TOKEN was present in its resolved launch environment, but Paperclip removed its name from shell_environment_policy.include_only. A live removal check also showed that an identity-free launch without an explicit policy could inherit an unassigned host token. **Expected behavior** An explicitly assigned service credential reaches shell commands. Removing that binding removes its shell access on the next launch. Unassigned host credentials stay outside the allowlist. Codex login credentials and observability headers keep their separate provider paths. **Steps to reproduce** 1. Configure a Legacy Codex agent with a synthetic SLACK_BOT_TOKEN value. 2. Run a shell command that checks whether the variable exists without printing its value. 3. Before this fix, the variable is absent. Repeat through ACP and CLI. 4. Remove the binding and run a second turn. Check that neither the removed token nor an unassigned host token reaches the command. **Paperclip version or commit** Reproduced in the executor regressions before the fix on master at4dfcb4c9b8. The final change is rebased on25f2d05282. **Deployment mode** Source checkout. Local macOS arm64 provider acceptance with Codex CLI 0.160.0 and Codex ACP 1.6.2, gpt-5.6-sol, and an existing ChatGPT login. ## What Changed - Added one shared Codex shell-name policy for Legacy ACP and CLI execution. - Admit explicitly resolved service-secret bindings. Keep Codex login keys, observability credentials, and private runtime transport tokens outside that opt-in. - Reject glob-shaped environment names so one configured name cannot match other credentials. - Always emit the bounded policy. Do not fall back to host inheritance after a binding is removed. - Updated executor regressions, the identity contract, and the paired verification maps. ## Verification - Red before the fix: executor regressions failed because SLACK_BOT_TOKEN was absent in ACP and CLI, with and without agent identities. - Green: 267 tests passed across the two executor suites and the shared shell-policy suite. Coverage includes host/provider isolation, unresolved and removed bindings, glob names, identity delivery, and names-only metadata. - The complete Codex adapter source suite passed after the CI follow-up: 571 tests passed, 1 skipped across 31 files. Its typecheck also passed. - The first CI run caught four stale expectations in ACP config and SSH launch tests. Those now assert the bounded policy and the existing command/resume behavior. No production code changed in that follow-up. - Live CLI and ACP acceptance: run a Python presence check through each real adapter, remove the synthetic Slack binding, and run again. The assigned token was present only on the first turn. The unassigned host token and OpenAI API key were absent on both turns. CLI retained its session; ACP correctly invalidated its session after the configuration changed. Workspace proof files persisted. - An earlier live CLI check failed after binding removal because the no-policy fallback exposed the synthetic host token. The final change removes that fallback. Both live checks then passed. - Full pnpm -r typecheck and pnpm build passed. The changed packages were compiled again after the safety correction. - node scripts/check-maps.mjs and git diff --check passed. - The local pnpm test:run attempt reported failures in native warm-session tests and was interrupted. That full-suite result is not a pass; PR CI must establish the final repository-wide gate. One named native failure passed alone, and the complete native executor file then passed separately (774 tests). The original broad-run failure cause remains unconfirmed. - After rebase, one Gemini skill-root case timed out at five seconds while the broad run was active. The case passed alone, and the full focused set then passed again at the PR head (267 tests). The earlier timeout remains part of the verification record. - An initial broad adapter run failed because sandbox restrictions denied loopback listeners. Running the same suites with loopback access passed. ## Risks - Explicitly assigned service secrets now reach shell commands. This is the intended behavior change: assigning a credential authorizes the run to use it, and a model-directed command can read it. This is not a broker that hides assigned credentials from the model. Operators must assign only credentials and service permissions authorized for the run. Configuration and secret-access authorization remain with their existing owners. - Superagent initially flagged this intended assigned-credential exposure as a P2. The inline reply records the trust-model rationale and the documentation states it explicitly. The security scan on the final documented revision passed without any check override. - The launch policy contains names, not values. Log redaction remains in place. Provider login credentials and observability headers remain excluded from the service-secret opt-in. - Identity-free Codex runs now also receive a bounded policy. This removes reliance on the operator's inherited shell policy. - Existing explicit project exclude patterns retain their behavior; #16255 addresses that separate case. - The change has not been deployed to a shared instance. ## Model Used OpenAI GPT-6 through Codex, with reasoning, repository tools, and code execution. The exact served 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 - [x] My branch name describes the change and contains no internal Paperclip ticket id or instance-derived details - [x] I have run the focused tests locally and they pass; the full-suite limitation is recorded above - [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>
@paperclipai/adapter-utils
Shared utilities for Paperclip adapters: process spawning, environment injection, sandbox/SSH transport, workspace sync, and the round-trip helpers that move code between the local execution-workspace cwd and wherever the agent actually runs.
For the adapter-author guide see
docs/adapters/creating-an-adapter.md
and the in-repo notes at packages/adapters/AUTHORING.md.
Sandbox bridge deadlines
Command-managed bridge control operations (queue reads, input delivery, setup, and cleanup) have a host-enforced deadline of at most 30 seconds per shell command. A shorter configured timeout still applies. These operations cannot inherit the agent run's hours-long lifetime or wait forever on a provider that ignores its timeout. Long-lived agent session commands keep their own limits.
A control timeout reports a transport failure. It does not prove that the remote command stopped and does not replay an uncertain write. The process session closes failed input delivery and uses its existing shutdown path; normal execution settlement must still verify termination.
No-remote-git contract
The local execution-workspace cwd is the only persistence boundary across runs. No adapter may depend on a git remote for cross-run state.
Adapters that run the agent on a different host should use the SSH round-trip
helpers in src/ssh.ts:
prepareWorkspaceForSshExecution({ spec, localDir, remoteDir })— bundles the local cwd (tracked files, dirty edits, untracked additions, and the git history needed to reconstruct it) toremoteDirbefore the run starts. Runs with nogit remoteconfigured.restoreWorkspaceFromSshExecution({ spec, localDir, remoteDir, ... })— syncs the remote cwd back intolocalDirafter the run, including any new commits the agent created. Also runs with nogit remoteconfigured.
prepareRemoteManagedRuntime in
src/remote-managed-runtime.ts wraps both
calls for adapters that want a per-run remote workspace and an automatic
restoreWorkspace() finally hook.
The invariant is pinned by the no-remote-git contract case in
src/ssh-fixture.test.ts, which asserts that a
remote-only commit propagates to the local worktree through the
prepare → restore round-trip with no git remote configured at any point. Do
not regress that test.