You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test(pr-verify): probe Bash for the capture's driven session in the sibling sandbox #13711
PR capture's driven session runs --restricted, which removes Bash, so a plugin hook that fires only on Bash tool events is recorded but never driven (PLAN Phase 1 F2). Hook changes on Bash events get no capture evidence.
Decision
Owner, 2026-11-06 (issuecomment-6686203326), Q8 (a): accept this for now; probe Bash in the sibling sandbox as a follow-up.
Done when
A runner probe (throwaway branch, no secrets, stub proxy, as the Phase 5b probe) launches the driven session with Bash available inside the sibling sandbox and shows a Bash-event hook firing, with the sentinel unseen and egress refused.
If it holds, the capture enables Bash for the driven session; if not, the reason is recorded here and the issue closes as won't-do.
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Medium
Uncertainty: Known
Flags: none
Blocked by: none
Decision recorded on this issue:
Decision recorded. Owner, 2026-11-06, in session (Lane 6), on Q12 (may the PR capture's driven session run without the subprocess scrub and --restricted, so it has Bash): "Q12 - yes". Option 1: approve. #13746 merges after its CI and review lanes pass at 58b1ddb or later.
That decision settles the open question. The probe result is already posted. Bash works in the sibling sandbox with the scrub off, with the sentinel unseen and egress refused. What remains is the capture change, which is in #13746. #13710 touches the same capture wiring, so the two may need coordinating. No duplicates found.
Not admitted to the issue lane: its done-when asks for what an unattended lane run cannot perform: item 7 (tracker-output: "If any observation fails, the reason is recorded on this issue, the capture i..."); recommended split: keep the other items here as the admissible issue and move these to a child issue for the host queue (host-run); it carries host-run. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).
Probe result: holds with the subprocess scrub off for the driven session.
Branch probe/13711-bash-sandbox at 6764ca0 (.github/workflows/probe-13711-bash.yml). No secrets, stub listener in place of the proxy.
Run 42247376450: every variant with CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1 failed the driven Bash call with bwrap: Creating new namespace failed: nesting depth or /proc/sys/user/max_*_namespaces exceeded (ENOSPC). The scrub runs Bash in its own PID-namespace bwrap, and the sibling sandbox's --disable-userns refuses that nested namespace. Claude Code's own sandbox (sandbox.enabled) fails the same way with the scrub on.
Run 42248541058, job capture (no-scrub, null, 0): the driven Bash returned error=false, content probe\nuid=1001 pids_bash=11 pid1=bwrap\napikey_bash=set\nsentinel_bash=0\ncurl: (6) Could not resolve host: example.com\ncurl_https=6\ncurl: (7) Failed to connect to 1.1.1.1 port 80 after 0 ms: Couldn't connect to server\ncurl_ip=7\nnode_fetch=refused EAI_AGAIN\nproxy_env=none. PreToolUse and PostToolUse hooks fired for tool_name: "Bash". The sandbox probe reported "sentinel": 0 and "egress": "refused", and the sibling check passed.
Decision (Lane 6, on the evidence): turn on Bash for the capture's driven session with the scrub off for that session only. The outer key-holding leg keeps the scrub.
Basis: with the scrub off, the driven Bash can read only the sandbox's dummy key (sibling-init.sh:104, ccd-dummy-…). The real key is held only by the key proxy (pr-verify-capture.yml:31). The sibling sandbox stays the boundary (sentinel unseen, egress refused). PR code spending the key's credit through the proxy, within the token cap, was already accepted under option A (issuecomment-6671043587).
A PR follows. It copies the probe's launch shape exactly.
Decision recorded. Owner, 2026-11-06, in session (Lane 6), on Q12 (may the PR capture's driven session run without the subprocess scrub and --restricted, so it has Bash): "Q12 - yes". Option 1: approve. #13746 merges after its CI and review lanes pass at 58b1ddb or later.
Activity
github-actions commentedon Nov 6, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Medium
Uncertainty: Known
Flags: none
Blocked by: none
Decision recorded on this issue:
#13711 (comment)
That decision settles the open question. The probe result is already posted. Bash works in the sibling sandbox with the scrub off, with the sentinel unseen and egress refused. What remains is the capture change, which is in #13746. #13710 touches the same capture wiring, so the two may need coordinating. No duplicates found.
Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Nov 6, 2026
Not admitted to the issue lane: its done-when asks for what an unattended lane run cannot perform: item 7 (tracker-output: "If any observation fails, the reason is recorded on this issue, the capture i..."); recommended split: keep the other items here as the admissible issue and move these to a child issue for the host queue (
host-run); it carries host-run. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).melodic-automation-lanes commentedon Nov 6, 2026
The latest triage verdict holds nothing: admission moved the issue to
status: confirmed; its comment says why.10 remaining items
kyle-sexton commentedon Nov 6, 2026
test(pr-verify): pin the default permission mode in the #13711 probe
kyle-sexton commentedon Nov 6, 2026
Probe result: holds with the subprocess scrub off for the driven session.
Branch
probe/13711-bash-sandboxat 6764ca0 (.github/workflows/probe-13711-bash.yml). No secrets, stub listener in place of the proxy.CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1failed the driven Bash call withbwrap: Creating new namespace failed: nesting depth or /proc/sys/user/max_*_namespaces exceeded (ENOSPC). The scrub runs Bash in its own PID-namespace bwrap, and the sibling sandbox's--disable-usernsrefuses that nested namespace. Claude Code's own sandbox (sandbox.enabled) fails the same way with the scrub on.capture (no-scrub, null, 0): the driven Bash returnederror=false, contentprobe\nuid=1001 pids_bash=11 pid1=bwrap\napikey_bash=set\nsentinel_bash=0\ncurl: (6) Could not resolve host: example.com\ncurl_https=6\ncurl: (7) Failed to connect to 1.1.1.1 port 80 after 0 ms: Couldn't connect to server\ncurl_ip=7\nnode_fetch=refused EAI_AGAIN\nproxy_env=none. PreToolUse and PostToolUse hooks fired fortool_name: "Bash". The sandbox probe reported"sentinel": 0and"egress": "refused", and the sibling check passed.Decision (Lane 6, on the evidence): turn on Bash for the capture's driven session with the scrub off for that session only. The outer key-holding leg keeps the scrub.
Basis: with the scrub off, the driven Bash can read only the sandbox's dummy key (
sibling-init.sh:104,ccd-dummy-…). The real key is held only by the key proxy (pr-verify-capture.yml:31). The sibling sandbox stays the boundary (sentinel unseen, egress refused). PR code spending the key's credit through the proxy, within the token cap, was already accepted under option A (issuecomment-6671043587).A PR follows. It copies the probe's launch shape exactly.
kyle-sexton commentedon Nov 6, 2026
Decision recorded. Owner, 2026-11-06, in session (Lane 6), on Q12 (may the PR capture's driven session run without the subprocess scrub and
--restricted, so it has Bash): "Q12 - yes". Option 1: approve. #13746 merges after its CI and review lanes pass at 58b1ddb or later.