Skill sandbox + execution-log fixes (read-only fs, image resolution, dark-mode labels) - #314
Merged
Merged
Conversation
The Docker skill sandbox runs uv from a workdir under /app, which in the Compose backend image is the backend's own uv project. uv discovered that project, found the venv Python interpreter link broken in the throwaway sibling container, and tried to recreate the venv, failing on the read-only root filesystem. Run skills with 'uv run --no-project' so uv never discovers a surrounding project and runs the skill in its own isolated environment. Applied to both the Docker and subprocess paths.
The Skills Used, MCP, and Skill badges in the execution console and history dialogs used 'bg-primary/20 text-primary'. In dark mode the primary violet text on the translucent primary background has too little contrast. Switch to the app's readable violet badge pattern (text-violet-700 dark:text-violet-300) so the labels are legible in both light and dark themes.
Single container deployments failed with 'Skill Docker sandbox is enabled but the runner image could not be resolved' because 'docker inspect <hostname>' does not reliably return the running image there. Fall back to HEYM_CODEX_DOCKER_IMAGE, which the release image and Compose already set to the backend image (it always carries uv), and set an explicit HEYM_SKILL_IMAGE in the release Dockerfile.
mbakgun
changed the title
Skills rely on the backend's installed packages (python-docx, pypdf, ...), but the sandbox ran them in an isolated environment that lacked those packages, so real skills failed. Run skills with the backend's own venv interpreter (sys.executable, valid in the sibling because it uses the backend image) instead of uv, which also avoids uv discovering and repairing the backend project on the read-only filesystem. This supersedes the earlier uv --no-project approach. Also add a .dockerignore: without it, 'COPY backend/ .' copied the host .venv into the image, clobbering the clean uv-synced venv with host-path symlinks and leaving a broken Python interpreter (the source of the read-only repair error). Verified end to end on the single-container image: a python-docx skill runs non-root, with no Docker socket, no leaked secrets, and produces a real docx.
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
1 participant
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.
Follow-up fixes after the skill sandbox landed (GHSA-hcv7-mg77-pg73). Three independent issues, one PR.
1. uv project discovery on the read-only filesystem (deploy.sh)
Running a skill in the Docker sandbox on a Compose deployment failed with:
The sandbox
--workdiris the per-run workspace under/app/data/codex-workspaces/.... In the Compose backend image,/appis the backend's own uv project, souv runwalked up, discovered it, found the venv Python link broken in the throwaway sibling, and tried to recreate the venv on the read-only root filesystem. Fix: run skills withuv run --no-project(both Docker and subprocess paths) so uv runs the skill in its own isolated environment. Inline PEP 723 dependencies are still honored; writes go toUV_CACHE_DIR/HOMEunder the writable workspace. Verified by reproducing the exact error locally and confirming the fix.2. Runner image could not be resolved (single container image)
Single container deployments failed with:
docker inspect <hostname>does not reliably return the running image in that deployment. Fix: fall back toHEYM_CODEX_DOCKER_IMAGE, which the release image and Compose already set to the backend image (it always carries uv), and set an explicitHEYM_SKILL_IMAGEin the release Dockerfile.3. Unreadable purple execution-log labels in dark mode
The Skills Used, MCP, and Skill badges in the execution console and history dialogs used
bg-primary/20 text-primary; the primary violet text on the translucent primary background is too low contrast in dark mode. Switched to the app's readable violet badge pattern (text-violet-700 dark:text-violet-300).Verification
🤖 Generated with Claude Code