Repository navigation
Let the caller choose Codex's sandbox (CODEX_COMPANION_THREAD_CONFIG) - #1
Merged
Merged
Conversation
With CODEX_COMPANION_THREAD_CONFIG set, thread/start and thread/resume send the caller's Codex config for the run's mode instead of sandbox, approvalPolicy and cwd; each run starts its own app-server (no shared broker); and a run whose active permission profile is not the requested one stops before its first turn. plugin.json has no version, so each fork commit installs as an update. FORK.md says what differs from upstream. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Without a broker, `cancel` sent its turn interrupt to a fresh app-server that does not hold the run's thread, and its kill did nothing for a run that leads no process group (ESRCH), so runs went on. Now a run with CODEX_COMPANION_THREAD_CONFIG set interrupts its own turn and closes its app-server on SIGTERM/SIGINT, and the kill helper also signals the process itself when its process group is not found. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…or detached delivery) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…e plugin's own pids Codex's turn interrupt leaves commands running in the background, and on Linux its sandbox keeps them alive when the app-server dies, so the run now lists the processes below its app-server before it interrupts the turn and kills them afterwards. The kill helper's fallback for a pid that leads no process group now checks that the pid still runs one of this plugin's scripts, since a stale pid may belong to another program. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
When the run leads its process group (started with setsid), cancel's group signal reached the app-server at the same moment, and Codex tore down its outer sandbox processes before the run could list the command below them, which then survived. With the app-server in its own group, the signal reaches only the run. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lets the caller choose the Codex sandbox of a run, so that the research plugin's
research-codexcan give GPT reviews and tasks a sandbox in which they can run tests,uv runand scripts, while the reviewed repository stays read-only.FORK.mddescribes every difference from upstream.CODEX_COMPANION_THREAD_CONFIG(JSON keyed by the sandbox mode a command would use): thread/start and thread/resume send that Codex config instead ofsandbox,approvalPolicyandcwd. Each such run starts its owncodex app-server(no shared broker) in its own process group, and stops before its first turn unless Codex reports the requested permission profile. Bad JSON or a missing entry stops the run.cancel: a run interrupts its own turn on SIGTERM and kills the processes below its app-server; the kill helper also signals a run that leads no process group, after checking that the pid still runs one of the plugin's scripts.plugin.jsonhas noversion, so each commit of the fork installs as an update (Claude Code compares version strings).Without the variable, behavior is upstream's, apart from the kill-helper fallback.
Tests:
npm test(upstream's suite plustests/fork-thread-config.test.mjs),npm run build. Merge together with theupstream-syncPR, whichFORK.mddescribes.🤖 Generated with Claude Code