Component
Selected-content provider staging and reconciliation
Summary
A selected-content task launch can expose file tools whose absolute targets resolve to the original checkout instead of the Gitless provider stage. In one reproducible run, provider writes changed the original checkout while the approved disposable worktree remained byte-for-byte unchanged. The controller nevertheless returned provider success, candidate_recognized: true, worktree_changed_since_dispatch: false, and reconciliation available.
This appears to regress the isolation delivered for #111.
Sanitized reproduction
- Create a branch-backed disposable worktree and owner-private controller state/log directories.
- Use a reviewed provider-scope file that selects a bounded read set and a smaller write subset.
- Approve the exact selected-content transmission SHA and launch
task with the current literal model.
- Let the provider create and modify candidate files.
- Compare the disposable worktree and original checkout after the terminal result.
Observed:
- Provider file-tool events named absolute paths in the original checkout.
- The original checkout received all reported candidate files and modifications.
- The disposable worktree did not receive those candidate writes.
- One created file was also outside the provider scope's approved write set.
- Controller state still reported provider success, a recognized candidate, no worktree change since dispatch, and available reconciliation.
No prompts, repository content, customer evidence, credentials, absolute local paths, or raw provider logs are attached.
Expected behavior
- Provider file tools should be rooted only in the fresh Gitless staged workspace.
- Reconciliation should copy only authorized writes into the disposable worktree.
- Any original-checkout mutation or out-of-scope write should fail closed and prevent candidate recognition.
- Terminal state should distinguish provider completion from an admissible reconciled candidate.
Impact
This defeats the selected-content write boundary and can mutate a user's active checkout even when the caller deliberately uses a disposable worktree. It also makes the success envelope unsafe to treat as evidence that candidate bytes were isolated or scope-compliant.
Suggested tests
- A provider event using an absolute original-checkout target cannot alter that checkout.
- An out-of-scope created file causes terminal rejection.
- A run where the disposable worktree is unchanged but another checkout changed cannot report an admissible candidate.
- Reconciliation verifies both source stage identity and destination worktree identity before and after every write.
Environment
- codex-agy-worker skill: 0.16.0
- agy: 1.1.26
- OS/architecture: macOS arm64
Component
Selected-content provider staging and reconciliation
Summary
A selected-content
tasklaunch can expose file tools whose absolute targets resolve to the original checkout instead of the Gitless provider stage. In one reproducible run, provider writes changed the original checkout while the approved disposable worktree remained byte-for-byte unchanged. The controller nevertheless returned provider success,candidate_recognized: true,worktree_changed_since_dispatch: false, and reconciliation available.This appears to regress the isolation delivered for #111.
Sanitized reproduction
taskwith the current literal model.Observed:
No prompts, repository content, customer evidence, credentials, absolute local paths, or raw provider logs are attached.
Expected behavior
Impact
This defeats the selected-content write boundary and can mutate a user's active checkout even when the caller deliberately uses a disposable worktree. It also makes the success envelope unsafe to treat as evidence that candidate bytes were isolated or scope-compliant.
Suggested tests
Environment