fix(tools): reuse canonical container config across sandbox creators - #90050
Open
kentimsit wants to merge 3 commits into
Open
fix(tools): reuse canonical container config across sandbox creators#90050kentimsit wants to merge 3 commits into
kentimsit wants to merge 3 commits into
Conversation
Collaborator
Duplicate of #60815 — both route prompt probing, file tools, and execute_code through one canonical container-configuration projection so sandbox policy cannot diverge. |
Contributor
|
Thanks for the credit and for the careful cross-caller consolidation — glad #76911 could inform the coverage. Happy to help review or adapt if needed. 🚀 |
This was referenced Aug 23, 2026
1 task
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.
What does this PR do?
Hermes has four production paths that can create a container-backed environment: terminal commands, file tools,
execute_code, and the system-prompt backend probe. Terminal creation now uses the canonical_container_config_from_config()projection, but the other three paths still hand-copy different subsets of the same configuration.That makes behavior depend on which path creates or recreates the environment first. In production, a file-tool first creation reused a stale cross-process container without the current mount policy, while an
execute_coderecreation after idle cleanup lost its forwarded-variable policy.This change routes the remaining three callers through the existing canonical projection. It preserves all current defaults and keeps local and SSH behavior unchanged with
container_config=None.The shared-projection design was proposed in #60815 by @NaMinhyeok, but that PR is now conflicting. My August 7 coordination question about replacing it from current
mainreceived no reply. Currentmainnow already contains_container_config_from_config()for terminal and lazy task-environment creation, so this refresh reuses that helper.Prior reports and partial implementations informed this refresh: #30097 by @elozadaf, #35660 by @temalo, #35937 by @jsplec, #65367 by @0112358DEUS, #75296 by @MichaelHuangXiaofei, and #80744 by @tanjelly. The prompt-network work in #62023 by @sagitario-jpn, #76911 by @webtecnica, and #76926 by @a-yeyang also informed the behavior coverage. Thanks as well to issue reporters @Shaihaan, @nikolay-bratanov, @MichaelHuangXiaofei, @smfed, and @ariv374.
Related Issue
Fixes #84027
Fixes #16214
Fixes #75291
Fixes #76906
Related to #87995. Its separate working-directory and duplicate-network-flag concerns are outside this focused change.
Type of Change
Changes Made
tools/file_tools.pynow derives container settings from the canonical projection when file tools create the shared environment first.tools/code_execution_tool.pynow preserves forwarded variables, static environment values, mounts, Docker arguments, shared memory, and lifecycle policy when recreating an environment after cleanup.agent/prompt_builder.pynow uses the same projection for backend probes, includingdocker_networkandvercel_runtime.TERMINAL_*parser → projection → environment factory → fake Docker constructor test. It covers forwarded names, static values, extra arguments, shared memory, network lockdown, cross-process persistence, and orphan-reaper policy without starting Docker.How to Test
Run the focused caller and Docker-constructor regressions:
Result: 8 passed.
Run the prompt-probe regression:
Result: 1 passed.
Run the socket-dependent
execute_codesuites in an environment that permits Unix-domain sockets:Result: 79 passed.
Run static checks:
Results: Ruff passed; the Windows-footgun scan passed across 985 files.
The broader affected terminal/config group passed after rerunning socket-dependent cases with the required VM permission. The complete prompt-builder file has 64 passes and one unrelated existing failure caused by this executor treating
/tmpas a Git worktree; the new prompt regression passes independently.A full repository run is not claimed as green in this minimal dev environment. It was stopped after 3,953 passes because unrelated suites require optional
acpand Anthropic SDK dependencies that are not installed here, and several existing tests assume/tmpis outside a Git worktree. No live Docker container was started.Checklist
Code
fix(scope):,feat(scope):, etc.)pytest tests/ -qand all tests passDocumentation & Housekeeping
docs/, docstrings) — N/A; no public behavior or configuration surface changedcli-config.yaml.exampleif I added/changed config keys — N/A; no config keys changedCONTRIBUTING.mdorAGENTS.mdif I changed architecture or workflows — N/A; this reuses an existing private projectionScreenshots / Logs
N/A.