Skip to content

Define scope-authorized current-head exports#122

Open
misrasaurabh1 wants to merge 14 commits into
codex/phase1-hosted-media-omissionfrom
codex/scope-current-head
Open

Define scope-authorized current-head exports#122
misrasaurabh1 wants to merge 14 commits into
codex/phase1-hosted-media-omissionfrom
codex/scope-current-head

Conversation

@misrasaurabh1

Copy link
Copy Markdown
Contributor

Summary

  • authorize sandbox sessions with stable provider scopes instead of projection allowlists
  • bind current complete generation vectors and metadata offers to export attempts
  • define atomic retry, revocation, retention, canonical ordering, and one-pass receipt semantics
  • preserve the v1 projection-pinned compatibility reader during TTL drain

Validation

  • git diff --check
  • read-only architecture review: no blocker/high/medium findings

Stacked on the Phase 1 public branch so existing hosted-media and profiling work remains intact.

@vercel

vercel Bot commented Jul 23, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
locality Ready Ready Preview, Comment Jul 24, 2026 3:22am

@github-actions

github-actions Bot commented Jul 23, 2026

Copy link
Copy Markdown

Codex review

  • major crates/localityd/src/replica_materializer.rs:831
    The v2 terminal control is parsed and validated, but its writable_metadata is then discarded and only ReplicaMaterializationSummary is returned. A scope-authorized export with writable entries will publish files without persisting the SQLite rows/baselines/preconditions needed for loc status, loc diff, or loc push, so local edits can become invisible or unpushable. Minimal fix: return the validated terminal writable metadata from materialization and persist it through the writable session store as part of sandbox init, with a test that a v2 export containing a write-enabled entry creates the expected local writable state.

  • major crates/locality-protocol/src/lib.rs:1438
    validate_against_inventory only checks that each writable_entries item matches a delivered file; it does not check the reverse. A file can carry mutation-capable effective_actions in PAX/inventory but be omitted from writable_entries, and the client will accept the archive without the remote IDs/preconditions required to track or push edits for that write-enabled file. Minimal fix: require the set of mutation-capable delivered files to exactly match the writable metadata entries, or reject/downgrade files whose writable metadata is absent; add a negative protocol/materializer test for a mutable file omitted from writable_entries.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant