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
loop-lane: research read-only preferences and sandbox completeness for local lanes #7680
The claude.dev post "Building effective agent automations" (2026-10-08, https://claude.dev/blog/building-effective-agent-automations/) has its agent read a preferences file it must not edit, protected by an Edit deny rule and a sandbox denyWrite entry. That pair is complete only when the sandbox is enabled (it is off by default), allowUnsandboxedCommands is false, no command that could write the file is in excludedCommands, and file-writing MCP tools are denied. CI lanes already meet this: they never read config back from their own telemetry and resolve config from the base SHA. Digest entry 13.
Question
Do any local lanes read, at run time, a preferences or config file the lane itself could edit? For each one, are all four conditions met?
Acceptance criteria
A list of local lanes that read an editable preferences or config file at run time, each with the file and where it is read.
For each listed lane, each of the four conditions marked met or not met, with evidence.
If the list is empty, the issue closes with that finding and no convention change.
If not empty, the loop-lane convention gains the four-condition note, and each unmet lane has a follow-up.
Proposed work class: work-class: read-only
Basis: automated intake triage; the lanes App applied this class.
Size: Medium
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none
I understood this as a read-only audit. It covers the three local lanes (work-loop, attend-queue, babysit-loop). For each lane it finds any editable preferences or config file read at run time. It then marks the four sandbox conditions met or not met, with evidence. If any lane qualifies, the loop-lane convention gains a four-condition note and each unmet lane gets a follow-up issue. If none qualifies, the issue closes with that finding. The refinement comment already lays out the acceptance criteria. The work is docs and research only, so I rated it low priority. #9726 is related: it moves babysit-loop's config keys, so the audit may need to cite the new read site. It does not block this issue. Nothing is missing, and I found no duplicates.
Not admitted to the issue lane: no trusted-human acceptance criteria: a listed human must put the confirmed - [ ] criteria in the body or post them as their own comment, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited. 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 commented on Oct 25, 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: Produce a written audit of the three local lanes (work-loop, attend-queue, babysit-loop) naming any editable preferences or config file each reads at run time and marking the four sandbox conditions met or not met, then add the four-condition note to the loop-lane convention only if a lane qualifies.
Acceptance criteria
The audit lists each local lane in docs/conventions/loop-lane/README.md section 5 (work-loop, attend-queue, babysit-loop) and says for each whether it reads an editable preferences or config file at run time, with the file and the path:line where it is read.
babysit-loop is checked against its tracked config seam (docs/conventions/source-control.yaml and .claude/source-control.local.md, per README.md:895) and work-loop against its launch args only (README.md:893), with the result stated.
For each listed lane, the four conditions are each marked met or not met with evidence: sandbox enabled, allowUnsandboxedCommands false, no file-writing command in excludedCommands, file-writing MCP tools denied.
The sandbox conditions are checked against the live Configure sandboxing page at code.claude.com/docs/en/sandboxing and plugins/harness-config/skills/audit/reference/required-permissions.md:79-98, and both are cited.
If the list is empty, the finding is stated in a comment on #7680 and no file under docs/conventions/loop-lane changes.
If the list is not empty, docs/conventions/loop-lane/README.md gains a note naming the four conditions near the Headless-config floor paragraph (README.md:891), and each lane with an unmet condition has a follow-up issue linked from #7680.
CI lanes are not audited.
Dependencies
#9726 changes how babysit-loop reads its keys from docs/conventions/source-control.yaml; if it lands first the audit should cite the new read site.
/home/runner/work/_temp/refine-data/context.json: issue body asks which local lanes read an editable config file and whether four sandbox conditions hold.
.base/docs/conventions/loop-lane/README.md:891-897: headless lanes never read run config from their own telemetry; work-loop takes launch args only; babysit loop reads launch args, then its tracked config seam, then tier defaults.
.base/docs/conventions/loop-lane/README.md:943-947: the local lane consumers are work-loop, attend-queue and babysit-loop.
.base/docs/upstream/claude-dev-building-effective-agent-automations.md:66: A13 is met for CI lanes; local lanes are to be researched under #7680.
.base/plugins/harness-config/skills/audit/reference/required-permissions.md:79-98: the sandbox escape-surface table covers allowUnsandboxedCommands and excludedCommands.
.base/plugins/source-control/skills/commit/SKILL.md:36: docs/conventions/source-control.yaml is the tracked team-layer config the source-control skills read.
Automated refinement by the lanes App. Admission counts only criteria a listed human wrote: to confirm these, post them as your own comment whose first line is **Decision recorded.**, which sends the issue back through intake.
Released for re-triage under the owner's 2026-10-24 rule: an issue stops for a person only for an intent or vision question, a security call, a host or attended run, or spend outside prepaid credit. The hold label came off and intake triage runs again now; it re-applies a hold, with a numbered question, when one of those applies.
To hold this issue again, add needs-human (or status: needs-decision) and say why in a comment.
Activity
github-actions commentedon Oct 16, 2026
Proposed work class: work-class: read-only
Basis: automated intake triage; the lanes App applied this class.
Size: Medium
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none
I understood this as a read-only audit. It covers the three local lanes (work-loop, attend-queue, babysit-loop). For each lane it finds any editable preferences or config file read at run time. It then marks the four sandbox conditions met or not met, with evidence. If any lane qualifies, the loop-lane convention gains a four-condition note and each unmet lane gets a follow-up issue. If none qualifies, the issue closes with that finding. The refinement comment already lays out the acceptance criteria. The work is docs and research only, so I rated it low priority. #9726 is related: it moves babysit-loop's config keys, so the audit may need to cite the new read site. It does not block this issue. Nothing is missing, and I found no duplicates.
Automated triage, applied by the lanes App.
github-actions commentedon Oct 25, 2026
The triage sweep dispatched intake triage for this issue (attempt 1 of 2).
melodic-automation-lanes commentedon Oct 25, 2026
Not admitted to the issue lane: no trusted-human acceptance criteria: a listed human must put the confirmed
- [ ]criteria in the body or post them as their own comment, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited. 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 Oct 25, 2026
The latest triage verdict holds nothing: the issue is at
status: ready.melodic-automation-lanes commentedon Oct 25, 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: Produce a written audit of the three local lanes (work-loop, attend-queue, babysit-loop) naming any editable preferences or config file each reads at run time and marking the four sandbox conditions met or not met, then add the four-condition note to the loop-lane convention only if a lane qualifies.
Acceptance criteria
Dependencies
Related work
Sources read
Automated refinement by the lanes App. Admission counts only criteria a listed human wrote: to confirm these, post them as your own comment whose first line is
**Decision recorded.**, which sends the issue back through intake.kyle-sexton commentedon Oct 25, 2026
Released for re-triage under the owner's 2026-10-24 rule: an issue stops for a person only for an intent or vision question, a security call, a host or attended run, or spend outside prepaid credit. The hold label came off and intake triage runs again now; it re-applies a hold, with a numbered question, when one of those applies.
To hold this issue again, add
needs-human(orstatus: needs-decision) and say why in a comment.