Skip to content

Selected-content task can write to original checkout while reconciliation reports success #127

Description

@cagdasyurekli

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

  1. Create a branch-backed disposable worktree and owner-private controller state/log directories.
  2. Use a reviewed provider-scope file that selects a bounded read set and a smaller write subset.
  3. Approve the exact selected-content transmission SHA and launch task with the current literal model.
  4. Let the provider create and modify candidate files.
  5. 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

Activity

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

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions