Repository navigation
fix(app-control): close the open threads pid-binding and eval follow-ups #9546
Description
Refs: #9532
Problem
PR #9542 added the threads capture kind to /app-control:drive and a thread-dump reading page to /debugging:analyze-profile. Its review rounds found the items below. They are outside the two pid-binding safety fixes that PR completed, so they were left open there.
Fix
Drive pid binding
- Race after the recheck. A target can exec a setuid binary with the same argv between the script's recheck and the recorder: pid, start time and cmdline hash survive exec. Recheck again after the recorder exits, and drop the capture on a difference.
- Platform. The integer-only uid and start-time rule leaves only Linux defined. On macOS and Windows a threads capture is blocked with no named reason. Either state that the binding is Linux-only with a named block, or give each platform's integer form.
- Under
runas. "The script's own uid, which is root" does not hold there. - Start-time parsing. Read
starttimefrom the fields after the last)of/proc/<pid>/stat, sincecommcan hold spaces or). - Order of checks. State which blocked line an invalid pid gets when unattended.
- Elevated attach. It has no binding: capture the attached pid's uid, start time and hash when the script is shown, and recheck them in the script.
- Other pid-targeting kinds. Pid binding covers only
threads. Extend it to thecpuandheaprecorders that take a pid, and say whether cleanup's stop rechecks first. - Secrets mark in
report.json. The table has no field for it (for examplesecrets_mark). - Body size. The drive body is 175 lines, above the measured max of 160 (
/skill-quality:check). Consider moving Pid binding to a reference spoke.
Evals
- Anchor the drive graders. In
threads-capture-blocked-unattended, anchorno-recorder-or-elevationandno-process-lookupto the"command":"value. Today they scandescriptionand heredoc text, and\bpsmisses a lookup after an escaped\n. no-shown-script. It catches only aWriteto a.shpath.names-a-second-dumpinanalyze-profile-reads-thread-dumpover-matches ("another thread holds…") and under-matches ("take two dumps", "run it again"). Replace it or fold it into the judge criteria.- Grader samples. Add
samples/<grader>.jsonfor every new grader. - No-edit grader. Add a grader for "no file edited" in the analyze-profile case, and align the
names-the-cyclesample's "proposes a fix" reason. - Interactive coverage. No case covers exit 3, a root-owned wrapper child, or the hash recheck. Add an interactive case.
Other
control-skill.mdkeeps manual pointers (dotnet-stack, GDBthread apply all,GOTRACEBACK) that the hang row no longer names. Keep them for the JVM, .NET, Go and native rows, or remove them.- analyze-profile's description does not name thread dumps (slice plan Q16, option a). Decide it with invocation probes.
Acceptance criteria
- Each item above is fixed, or closed with its reason in this issue.
- Each changed eval grader is tested against JSON-serialized tool input and has samples.
-
grep -nE '#[0-9]{3,}'over the changed skill files returns nothing.
Activity
kyle-sexton commentedon Oct 24, 2026
Added from the #9542 review: Bundle the recheck. Codex P1 on drive/SKILL.md suggests shipping the deterministic pid recheck as a bundled script instead of having the model generate it for each capture, so the recheck is tested code rather than prose followed per run. Weigh it against the shown-script route, where the person reads the exact commands before the yes.
github-actions commentedon Oct 26, 2026
The triage sweep dispatched intake triage for this issue (attempt 1 of 2).
github-actions commentedon Oct 26, 2026
Proposed work class: work-class: structural
Basis: automated intake triage; the lanes App applied this class.
Size: Large
Complexity: Medium
Uncertainty: Knowable
Flags: intent
Blocked by: none
Understood: a bundle of follow-ups from #9542 to the app-control drive pid binding, its evals, and two doc items. It's too big for one change and should be split. Three choices are left open in the text:
No duplicates found.
Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Oct 26, 2026
The triage verdict left this issue at
status: needs-decision:melodic-automation-lanes commentedon Oct 26, 2026
Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. On an issue a listed human filed, it counts as the issue's spec once posted, while unedited; it is still model text, so check it.
Intended outcome: Split the bundle into separate changes: pid-binding fixes in drive, eval grader fixes, and the two small doc decisions, each with its own checkable criteria.
Dependencies
Related work
Open questions
RECOMMENDED: Linux-only with a named blocked reason Basis: .base/plugins/app-control/skills/drive/SKILL.md:150
RECOMMENDED: Bundled script, with the shown script displaying its exact invocation so the commands stay visible Basis: comment by kyle-sexton on Codex P1, and intake triage item 2
RECOMMENDED: Yes: (1) drive pid-binding safety fixes, (2) extend binding to cpu/heap and elevated attach plus the secrets_mark field, (3) eval graders and samples, (4) body-size spoke move and control-skill.md pointers Basis: judgment: size Large per intake triage, and the acceptance criterion 'each item fixed or closed' is not checkable as one unit
RECOMMENDED: Decide only after invocation probes; leave out of this change until the owner runs them Basis: judgment: the issue itself defers it to probes, which an unattended run cannot judge
RECOMMENDED: Keep them on those rows Basis: intake triage item 4
Sources read
Automated refinement by the lanes App. Answer with a comment whose first line is
**Decision recorded.**.