feat(prompt-agent): a user-sim agent receives readable URLs for store-owned file parts too

[earakely-scale]

Summary

prompt_agent sends messages to two peers: the target agent, and the user agent that answers it in a multi-turn conversation. Only the first went through readable_parts (#57). The user agent was sent the target agent's reply parts unchanged. So a user-sim agent received a file part naming a store-owned object as the store's raw URL, which it can't read without the store's credentials.

Both sends now go through one helper, send_and_wait, in a2a_agent/object_transfer.py. It sends parts to an A2A peer and polls the task until it ends.

• A peer agent-env deployed (the target, or a user-sim running in a sandbox) is sent each file part a configured store owns as an HTTPS URL it can read, through readable_parts.
• A user-sim is made able to read only the files the target was sent in this conversation. A reply is the target's model output, and core must not mint a readable URL for any object it happens to name. prompt_agent collects the file URIs it sends the target and passes them as shareable. Any other store-owned URI in a reply is sent as it is, as before.
• Any other peer, such as a human-facing endpoint named by user_a2a_url or a registered human peer with no sandbox, reads the store itself. It is sent the parts as they are, so no signed URL is stored on its side.
• before_send runs once the parts are ready, just before the message goes out. The target's turn is still recorded there, so an object the agent can't be sent still leaves no turn waiting for a reply.

There are no other message sends to agents with file parts in core: the rubrics judge and the trigger executor send text only.

Tests

• Unit (prompt_agent_file_parts_test.py, readable_parts_test.py):

  • a user-sim is sent a file the target passes on as a grant;
  • a file the target names but was never sent reaches the user-sim as it is, with no grant;
  • a user-sim the store's grants can't reach gets a copy staged on it, staged before the message and cleared after the reply;
  • a user-sim that can be given no readable URL fails the step before it is sent anything;
  • registered and user_a2a_url human peers get the object's own URL;
  • readable_parts(shareable=...) makes only the named objects readable.

• Integration, new tst/integration/task_step/test_prompt_agent_file_parts_local.py, fast tier, on real local agents:

  • the echo agent now reports what each file part it's sent holds, and answers send-file <uri> with a file part;
  • the solver fetches its prompt file over a grant;
  • the user-sim fetches the file the solver passes back, and can't open one the solver names but was never sent;
  • both kinds of human peer are sent the store's own URL;
  • the conversation records only the store's own URLs.

  Before this change there was no integration test that sent an agent a file part.

• Mutant checks:

  • main's code fails the user-sim tests;
  • dropping the sandbox check fails the registered-human test;
  • this branch before shareable fails both guard tests.

• Suite: tst/unit + protocol, 6263 passed. CI's integration tiers pass.

• Plugin API: no break.

End-to-end and chaos results are in a comment below.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge; no new issue remains from the changes since the previous review.

Findings

1.  Human file reads go untested ▶

Fix with agent prompt

### Issue 1
tst/integration/task_step/test_prompt_agent_file_parts_local.py:undefined-189
The human-peer test now expects the peer to fail when reading the file. The test peer no longer opens `file://` URLs, so this test can pass even if the URL sent to a human peer points to the wrong file. Keep the test agent's safe reader, but check the sent URL against the store object or use a separate trusted reader to check its contents.

---

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

Summary

prompt_agent now prepares file parts for both deployed agents in a multi-turn conversation. User-sims get readable links only for files the target received, while human peers keep the store’s own URLs.

• Deployed agents get readable file links for shared files.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  Target[Target reply] --> Check{User peer}
  Check -->|Sandboxed user-sim| Shared{URI sent to target?}
  Shared -->|Yes| Readable[Grant or stage readable file]
  Shared -->|No| Original[Keep original URI]
  Check -->|Human peer| Original
  Readable --> Send[Send and wait]
  Original --> Send

Loading

_{Reviews (7) · Last reviewed commit: "Merge remote-tracking branch 'origin/mai..."}

[earakely-scale]

End-to-end and chaos results (final head 855d29b)

Setup:

• Real agents on remote sandboxes on two providers (Modal containers, and a VM provider), against a dev deployment whose S3 store issues grants.
• The solver is the echo test agent. Its prompt carries one store file, and it returns that file plus a second it was only told the URL of.
• The user-sims are the echo agent and two model-driven CLI wrappers (Claude Code, OpenCode).
• Large files are checked by sha256. Signed URLs are recorded redacted.

case	Modal	VM provider
grants: user-sim fetches the shared file; the never-sent file arrives as s3://	pass	pass
grants, 3 turns: the user-sim reads the shared file on each of its turns, through a fresh grant each time	pass	pass
no grants, signed URL	pass	pass
no grant or URL, staged on the agent	pass	fail*
staged, 3 turns: a copy is pushed before, and cleared after, each of the 3 sends that carry the file	pass	–
no URL or staging for the user-sim (on the other provider): the step fails before it is sent anything	pass	pass
human peer, by user_a2a_url and registered: sent the s3:// URLs as they are	pass ×2	pass ×2
256 MB shared file over grants: the solver's and the user-sim's sha256 match	pass	pass
256 MB over a signed URL	pass	–
64 MB staged	pass	–
Claude Code user-sim quotes the shared file's passphrase; the never-sent file's secret appears nowhere	pass	pass
Claude Code user-sim computes a 128 MB shared file's sha256 with a shell command	pass	pass
OpenCode user-sim	fail†	fail†
user-sim killed 8 s after it is sent the files	the agent is given up on after 61 s, the conversation ends and the step completes	the poll gets a 404 and the step fails‡

* VM-provider staging fails for the solver and the user-sim alike. Inside the VM, the agent's own public hostname presents a self-signed certificate (confirmed with a probe from the container). So the target path from #57 fails the same way. It's a platform issue, tracked separately.

† OpenCode fails its turn when a message carries an s3:// attachment. It rejects that scheme, as it does on main, and the conversation ends cleanly after turn 1. When the solver passed on only the shared file, OpenCode read it and quoted the passphrase on both providers.

‡ This is poll_a2a_task's handling of a 4xx, unchanged by this PR. The VM provider's gateway answers 404 for a dead VM.

Also checked on this head:

• feat(prompt-agent): agents receive store-owned file parts as HTTPS URLs they can read #57's file suite: Claude Code 9/9 on the VM provider, OpenCode 9/9 on Modal. This covers text, seeded URI, odd key, png, pdf, mp4, 64 MB sha256, public https, and a file forwarded in turn 2.
• feat(prompt-agent): agents receive store-owned file parts as HTTPS URLs they can read #57's staging suite (local store, OpenCode on Modal): text and 16 MB pass.
• Persisted signatures: 0 in every run, across conversations, run context and agent trajectories.
• Teardown: every sandbox terminated, apart from the deliberately killed ones.

Earlier rounds on 8c14a26 (the sharing fix) and e3d556c gave the same results for the cases they covered.

[greptile-apps]

Human file reads go untested

The human-peer test now expects the peer to fail when reading the file. The test peer no longer opens file:// URLs, so this test can pass even if the URL sent to a human peer points to the wrong file. Keep the test agent's safe reader, but check the sent URL against the store object or use a separate trusted reader to check its contents.

Knowledge Base Used: Storage, objects, documents, and secrets

Prompt To Fix With AI

This is a comment left during a code review.
Path: tst/integration/task_step/test_prompt_agent_file_parts_local.py
Line: 189

Comment:
**Human file reads go untested**

The human-peer test now expects the peer to fail when reading the file. The test peer no longer opens `file://` URLs, so this test can pass even if the URL sent to a human peer points to the wrong file. Keep the test agent's safe reader, but check the sent URL against the store object or use a separate trusted reader to check its contents.

**Knowledge Base Used:** [Storage, objects, documents, and secrets](https://app.greptile.com/scale-ai/-/custom-context/knowledge-base/scaleapi/agentenv-framework/-/docs/storage-and-secrets.md)

---

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

[earakely-scale]

Fixed in 8f7cf7e: the in-process peer records the file URIs it is sent, and the test asserts they are exactly the store object's own URL.