Supported path for remotely initiated Codex work with existing tools and approvals

[dwyler741]

We’re evaluating Paperclip for remotely initiated Codex work. From the v2026.1012.0 docs, codex_local and the native Runner manage their own runtime sessions, while Assistant Connection lets an existing assistant delegate work to Paperclip.

Is there a supported path to submit work to an existing Codex Desktop conversation while retaining its tools and approval handling? If not, which released architecture do you recommend for persistent state, configured tools, questions/approvals across restarts, and reliable result delivery?

Does native Codex’s required permission mode “never” mean approvals must instead be implemented through Paperclip’s governed tools? Please point to a working example and supported versions.

[lab1207]

Short version, verified at upstream master 7a8b3583: there is no supported path into an existing Codex Desktop conversation. Every Paperclip adapter owns its runtime sessions. The supported shape is the reverse: keep your existing assistant and delegate into Paperclip, or run the work under an adapter where Paperclip owns the session. Per sub-question:

1. Existing Desktop conversation: no. codex_local resumes only Paperclip-side sessions (packages/adapters/codex-local/src/server/execute.ts:1069-1079, persisted session id plus cwd/remote-identity match at :1083-1088), spawned under an isolated per-agent Codex home (doc/DEVELOPING.md:890), never the Desktop app's threads. Nothing in the adapter addresses a Desktop conversation id.

2. Recommended architecture: Assistant Connection + codex_local. Connectors → Assistant Connection (MCP) → Set up lets an outside assistant delegate work to Paperclip under your human account (doc/public-mcp.md:47-69; needs the experimental flag, consent per connection). For Paperclip-owned runs, codex_local gives persistent state (issues), configured tools, and resume across restarts. Agent creation example: doc/CLI.md:534.

3. The never mode, precisely. "Paperclip Runner currently supports Codex only with codexPermissionMode set to never" (packages/adapters/codex-local/src/ui/build-config.ts:183-186). On the codex_local CLI engine the bypass is passed directly (--dangerously-bypass-approvals-and-sandbox, pinned in codex-args.test.ts). So yes: model-level approvals off, and approval authority moves up to Paperclip's gates — board approvals API (doc/SPEC-implementation.md:1289-1294) and governed actions (:1498+).

4. Working example. The public-mcp.md setup flow above is the maintained one (manual Codex tab included at :64-69); verify paperclip_connection before delegating work.

Confirm it works: connect, verify, delegate one small task, and check the run, its approvals, and its resume behave across a restart.

Three caveats. I have not paired a live Desktop app against this (that needs both ends; Desktop-side targeting would need upstream Codex support that does not exist). codex_local needs the codex CLI installed and authenticated on the host (DEVELOPING.md:896). And I verified these paths at current master; your build is v2026.1012.0, so confirm the Assistant Connection experimental flag exists there before relying on it.

[IlyaKhalafi]

One qualification on the approvals part. codexPermissionMode="never" does not establish that Paperclip will approve every shell command or file write. Official OpenAI documentation treats the approval policy and sandbox configuration separately.

In v2026.1012.0, the CLI adapter’s argument builder defaults to --dangerously-bypass-approvals-and-sandbox, with configuration overrides. That flag removes Codex’s own approval and sandbox checks. The execution wrapper can separately apply a process sandbox for local execution targets when filesystem or network scopes are configured.

Paperclip’s governed-action approvals therefore should not be treated as evidence that arbitrary Codex shell or file actions are intercepted. The native Runner separately launches codex app-server with approvalPolicy="never". Its effective permissions need checking separately from the CLI flags.

For qualification, test a denied filesystem operation and an approval-required Paperclip action independently, then repeat after restart. That checks both boundaries instead of inferring them from the permission-mode name. I checked the release source, not a live deployment or approval-resume workflow.

[lab1207]

Verified on current master, and thanks — this sharpens point 3. The checks:

• The CLI adapter defaults to bypass. resolveCodexLocalCliPolicy in packages/adapters/codex-local/src/index.ts returns bypass: true unless extraArgs carry an explicit sandbox or permission flag, or networkAccess is false (DEFAULT_CODEX_LOCAL_BYPASS_APPROVALS_AND_SANDBOX = true). The config boolean dangerouslyBypassApprovalsAndSandbox overrides this both ways, and the argument builder then adds --dangerously-bypass-approvals-and-sandbox.
• The execution wrapper builds a separate process sandbox for local targets when filesystemScope or networkScope is configured. It logs "Confining Codex with … scope." and wraps the command with bwrap by default.
• The native Runner is a separate launch path with approvalPolicy: "never" (native-codex-runner.ts), as you note.

So the boundary is: Codex's own approval and sandbox checks are off by default; Paperclip's governed-action approvals gate actions that flow through Paperclip's control plane, not arbitrary shell or file operations inside a run; and runtime confinement comes from the configured execution scopes. Point 3 of my answer should read that way. I also agree with your qualification test: check a denied filesystem operation and an approval-required Paperclip action independently, before and after a restart.