2 Commits

Include renames

Author	SHA1	Message	Date
AlexFrontegg	57658fcb30	fix(codex): pass the run's GitHub broker capability to shell commands (#17605) ... ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - When an execution has managed GitHub, Paperclip gives it token-free `git` and `gh` launchers. Each launcher call gets the run's credential from the broker with a per-run capability (`PAPERCLIP_GITHUB_BROKER_TOKEN`). > - The launchers run inside the agent's shell commands and read the capability from their environment. > - #17216 limits the environment of Codex shell commands to an allowlist, and it keeps every `PAPERCLIP_GITHUB_*` name out. > - So on legacy Codex through ACP, the launchers do not get the capability, report `capability_missing`, and continue without credentials. > - The native runner already passes the same names to its Codex provider (`GITHUB_CREDENTIAL_ENVIRONMENT_KEYS` in `packages/paperclip-runner/runner/crates/runner-core/src/codex_provider.rs`). > - This pull request adds the broker capability to the legacy Codex shell allowlist when Paperclip set it for the run. > - The benefit is that managed `git` and `gh` work again for legacy Codex agents. ## Linked Issues or Issue Description Fixes #17599 Refs #16549, #17216 ## What Changed - `packages/adapter-utils/src/codex-shell-environment.ts`: the shell allowlist also includes `PAPERCLIP_GITHUB_BROKER_TOKEN` and `PAPERCLIP_GITHUB_BRIDGE_TOKEN` when they have a value in the run's environment. Only the names enter `shell_environment_policy.include_only`. The values stay out of the Codex config and the arguments. - `packages/adapter-utils/src/codex-shell-environment.test.ts`: a new test for the capability. The "runtime transports" test no longer lists the broker token, because the launchers need it in the shell. ## Verification - `pnpm --filter @paperclipai/adapter-utils exec vitest run src/codex-shell-environment.test.ts`: 5 passed. The new test fails without the change. - Before the change, on a deployment with a legacy Codex agent that has managed GitHub, `gh pr view` in a shell command fails with `Paperclip: GitHub capability_missing; continuing without managed credentials`, and the shell has the broker URL but not the broker capability. I will add the result after the change is deployed there. ## Risks - Codex shell commands can now read the run's broker capability. The broker accepts it only while the run is live (`captureRunIdentity` requires `status === "running"`), and it returns the credential that the managed `gh` command receives anyway. - Agents cannot set these names in their configuration. `stripForbiddenEnvBindings` removes them (`server/src/services/heartbeat/run-preparation.ts`) before the server adds the run's own values. - No change for runs without managed GitHub: Paperclip does not set the capability, so the allowlist does not add it. ## Model Used - Provider and model: Anthropic Claude Opus 5.5 (`claude-opus-5-5`), used through Claude Code. - Capabilities used: tool use, code execution (local tests and type checks), and repository search. - A human reviewed the diagnosis and the change before this pull request was opened. ## 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) - [ ] 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 - [ ] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge	2026-10-29 13:18:49 -07:00
DottaandPaperclip	042051904d	fix(codex): deliver configured service secrets to shell tools (#17216) ... ## 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 at 4dfcb4c9b8. The final change is rebased on 25f2d05282. **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>	2026-10-22 18:17:34 -05:00