Skip to content

loop-lane: research read-only preferences and sandbox completeness for local lanes #7680

Open

Description

@kyle-sexton

Context

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.

Related

None.

Out of scope

  • CI lanes (already met).

Activity

  1. added
    needs-triageNot yet classified. Floor until a type and one priority tier are set.
    on Oct 16, 2026
  2. github-actions commented on Oct 16, 2026

    @github-actions
    Contributor

    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.

  3. added
    priority: mediumReal value, no hard deadline; normal backlog flow.
    and removed
    needs-triageNot yet classified. Floor until a type and one priority tier are set.
    on Oct 16, 2026
  4. github-actions commented on Oct 25, 2026

    @github-actions
    Contributor

    The triage sweep dispatched intake triage for this issue (attempt 1 of 2).

  5. added
    status: readyTriaged, unblocked, and fully specified; eligible to pick up.
    work-class: read-onlyAudits, research, reports. No repository mutation; tracker and queue writes only.
    status: needs-decisionAwaiting a human or maintainer judgment call.
    and removed
    status: readyTriaged, unblocked, and fully specified; eligible to pick up.
    on Oct 25, 2026
  6. melodic-automation-lanes commented on Oct 25, 2026

    @melodic-automation-lanes
    Contributor

    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).

  7. melodic-automation-lanes commented on Oct 25, 2026

    @melodic-automation-lanes
    Contributor

    The latest triage verdict holds nothing: the issue is at status: ready.

  8. melodic-automation-lanes commented on Oct 25, 2026

    @melodic-automation-lanes
    Contributor

    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.

    Related work

    Sources read

    • /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.

  9. kyle-sexton commented on Oct 25, 2026

    @kyle-sexton
    MemberAuthor

    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.

  10. added
    status: readyTriaged, unblocked, and fully specified; eligible to pick up.
    admission-deferredReady for the issue lane; work-unblock admits it when queued work is under the queued cap
    agent-readyFully specified and briefed; eligible for autonomous pickup from the frontier.
    and removed
    admission-deferredReady for the issue lane; work-unblock admits it when queued work is under the queued cap
    on Oct 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    agent-readyFully specified and briefed; eligible for autonomous pickup from the frontier.priority: lowNice-to-have, cosmetic, or speculative; opportunistic.priority: mediumReal value, no hard deadline; normal backlog flow.status: readyTriaged, unblocked, and fully specified; eligible to pick up.work-class: read-onlyAudits, research, reports. No repository mutation; tracker and queue writes only.

    Type

    Fields

    No fields configured for Task.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions