[earakely-scale]

Why

agent-env bundle init writes a stored task into a folder you can run and edit. Registering that folder back should keep the task what it was. The folder's entities should go back to the ids they came from, and an untouched folder should write nothing. An edit should re-version only what it reaches, without losing the fields the import left out.

Stacked on #355 (bundle register), and it includes #353's commit (the import record v2), which this is the reader of. If you'd rather review one PR for the import side, close #353 and merge this after #355.

What it does

When the folder's provenance.json records an import from the configured store (its store fingerprint matches):

• Ids: each entity, image, task and eval takes the store id it was imported from. An imported task's outputs keep the names its file gives them, as the stored task did. Only ids register makes up are held to the registry id rule, so a source id like nightly/regression passes.

• Untouched folders write nothing: a write whose files are as the import wrote them keeps the version it was imported at, as long as everything it needs is kept at the versions they were imported at too. The ledger records that version, so later runs compare digests as usual. The files compared are:

  • a task's or eval's file;
  • an image's build context;
  • an env's or agent's toml, or the whole folder for an env type written from its folder;
  • every file of an artifact or skill.

  This compares against the import's file hashes, not the stored entity's digests, because import prunes contexts and pins their installs.

• Edits re-version only the edited write and what references it.

• Re-grafting: each imported task's steps get back the user-scoped fields the import left out, such as the agent, env vars, sandbox type and model. They come from the stored version, matched by step id and type, wherever the folder doesn't set them. A shared store's credential and loopback-URL checks skip these fields, since the store holds them already.

• A version someone else wrote since the folder was imported is refused, unless --adopt.

A folder imported from another store, or recorded by an older agent-env, registers as a new bundle with prefix ids, and the run says why.

Verification

Unit tests: tst/unit/bundle/register_imports_test.py, 8 tests, plus #353's import-record tests. They cover:

• an unedited import writes nothing, keeps every version, and records rows;
• an edit re-versions only the edited artifact and its task, and gives back the agent and env vars;
• a re-grafted field isn't refused as a credential on a shared store;
• an edit over a version the store wrote since is refused until --adopt;
• an edited Dockerfile pushes a new image and rewrites its env;
• another store's import, and an older record, register as new bundles;
• an imported task's output keeps its name.

The full unit tier passes: 10,912 passed. One a2a staging timing test failed once under load (the run took 15 minutes instead of 2) and passes 3/3 alone; this PR doesn't touch it.

Open-source stores on an agent-environments-admin VM (Mongo, SeaweedFS S3, and a TLS registry with auth):

• echo-mcp registered, then imported from those stores with bundle init. Registering the folder back, as a dry run and for real, kept every entity at its source id and v1, writing nothing.
• A git clone of the imported folder on another path still registered as untouched.
• Editing the check re-versioned only the check and the task, v2 ran, score 1.0.
• An edited Dockerfile gave image, env and task new versions, and the new task ran, score 1.0.
• After another write took the check to v3, an edit was refused, then written as v4 with --adopt.
• No version was written twice, no pending rows were left, and no secret text appeared in any results.

Dev stage, from a laptop, since the dev cluster isn't reachable from the admin VM:

• The fd3965-e2e-echo-smoke task feat(bundle): agent-env bundle register writes a bundle into the configured stores #355's e2e registered was imported and registered back untouched, writing nothing.
• Its edit wrote only the check and the task, v2. The new version got back the sandbox_type: local the import had dropped, and ran on a Modal VM, score 1.0.
• The real task-rocket-prospecting-christina-rivera-v1 (v7) was imported with --include-scope user and dry-run registered. All 21 writes showed as unchanged at their source versions, and nothing was written. The writes are 9 MCP-server envs and their images, the multi-env, the claude-code-cli agent (v74) and its image, the universe artifact, and the task.
• A plain import of rocket fails in bundle init itself. Two of its stored build contexts hold several Dockerfiles and record none, which import already refuses without --include-scope user.

🤖 Generated with Claude Code

Confidence Score: 4/5

Fix the masked URLs saved after filename edits before merging.

Findings

1.  Renamed downloads lose credentials ▶

Fix with agent prompt

### Issue 1
src/agent_env/bundle/_imported.py:256-257
After importing with `--include-scope user`, changing `urls[].filename` prevents `_counterpart()` from finding the stored download-even when it is the list's only item. Registration then saves the masked `url` instead of restoring the original URL. Downloads that require those credentials stop working.

Match safely where possible, and refuse registration when a masked value cannot be restored rather than silently saving it.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR registers imported folders under their original store IDs and versions, restores omitted task settings, and reuses untouched writes.

• Imported folders register under the store IDs they came from.
• Imported task steps regain settings that the folder left out.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Imported folder] --> B{Same store and supported record?}
    B -->|No| C[Register with generated IDs]
    B -->|Yes| D[Keep source IDs and restore omitted settings]
    D --> E{Files and dependency versions unchanged?}
    E -->|Yes| F[Reuse imported versions]
    E -->|No| G[Check ownership and write changed versions]

Loading

_{Reviews (7) · Last reviewed commit: "fix(bundle): restore a masked value in a..." · Reviewed by Greptile}

[greptile-apps]

Renamed downloads lose credentials

After importing with --include-scope user, changing urls[].filename prevents _counterpart() from finding the stored download—even when it is the list's only item. Registration then saves the masked url instead of restoring the original URL. Downloads that require those credentials stop working.

Match safely where possible, and refuse registration when a masked value cannot be restored rather than silently saving it.

Prompt To Fix With AI

This is a comment left during a code review.
Path: src/agent_env/bundle/_imported.py
Line: 256-257

Comment:
**Renamed downloads lose credentials**

After importing with `--include-scope user`, changing `urls[].filename` prevents `_counterpart()` from finding the stored download—even when it is the list's only item. Registration then saves the masked `url` instead of restoring the original URL. Downloads that require those credentials stop working.

Match safely where possible, and refuse registration when a masked value cannot be restored rather than silently saving it.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.