V1 artifacts not listed for finished runs (self-hosted workers)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)? API V1 and self-hosted workers

Hello,

We are using Cloud Agents API v1 with self-hosted Cursor workers on Kubernetes, and we’re seeing missing artifacts for finished runs.

Context

  • API version: v1
  • Auth: Basic auth (api_key:)
  • Worker model: self-hosted (cursord namespace, worker deployment cursor-workers)
  • Worker workspace: /workspace
  • Expected artifact path written by the agent:
    artifacts/support-recommendations-1303.json

Issue

For multiple runs, GET /v1/agents/{id}/runs shows FINISHED, but:

  • GET /v1/agents/{id}/artifacts returns 200 with items: []
  • expected path is never listed
  • downstream artifact download cannot proceed

Agents/runs affected

  • bc-2b906ba6-2a48-426f-8e1a-9770b7c227ab / run-254a330c-0120-40c9-a8b7-9760f95aa7f2 (FINISHED)
  • bc-33a76734-4090-4c5a-b385-482884b4e39e / run-cb7405a8-b1c4-40b7-8ed2-0dbea3962923 (FINISHED)
  • also observed on bc-d9bfac92-58d8-40fd-ad74-90b9d28b101a (FINISHED)

What we already validated

  1. Path is correct in our metadata (artifacts/recommendations.json), no typo/case mismatch.
  2. Agent/run mapping is correct (same IDs returned by v1 runs endpoint).
  3. Not a timing race: artifacts re-checked well after run completion, still empty.
  4. Worker filesystem is writable:
    • manually created /workspace/artifacts in a running worker pod
    • wrote/read/removed a test file successfully.

Why this looks like a platform/indexing mismatch

Run output text says the artifact was written at the expected path, but artifact listing stays empty for that same agent/run.

Questions

  1. In v1 with self-hosted workers, what exact conditions make a file appear in GET /v1/agents/{id}/artifacts?
  2. Is artifacts/... always sufficient, or are there additional constraints?
  3. Can a run report local file creation while artifact indexing still skips it?
  4. Any known v1 + My Machines limitations/bugs around artifact indexing?
  5. Is there a diagnostic endpoint/log to inspect artifact indexing per run?

Happy to share full raw responses and timestamps if useful.

5

Hey, thanks for the detailed report. It already has everything we need to diagnose this.

This looks like a gap in our docs, not a code bug. The artifact pipeline for a self-hosted worker works like this: the agent writes a file to the local artifact directory → the exec-daemon on the worker uploads it to Cursor’s artifact storage AWS S3 in us-east-1 via a presigned PUT → the V1 API lists artifacts by reading objects from that bucket. If outbound HTTPS from the worker pod to S3 is blocked by an egress policy, the upload quietly becomes a no-op, the run still ends as FINISHED, and /artifacts returns an empty list.

Please check that egress from the cursord namespace allows outbound HTTPS to:

  • cloud-agent-artifacts.s3.us-east-1.amazonaws.com (or more broadly, AWS S3 in us-east-1)

In the current setup docs we only list api2.cursor.sh, api2direct.cursor.sh, downloads.cursor.com. Artifact storage is not mentioned there. That is a known docs gap and we’re fixing it on our side.

Quick answers to your questions:

  • The file will show up in /v1/agents/{id}/artifacts only after the exec-daemon successfully uploads it to S3. Writing to /workspace/artifacts/ locally is not enough.
  • The artifacts/... prefix is enough. There are no extra constraints on the path or filename.
  • Yes, that’s exactly what happens. A run can report a local write, but if the upload step failed egress, proxying, the index will be empty.
  • In this case the likely reason is blocked egress to S3. Also, right now the upload path does not respect the HTTPS_PROXY env var, so if you require mandatory proxying that is another possible cause.
  • There is no separate per-run diagnostic endpoint. The best signal on your side is the exec-daemon logs in the worker pod during or right after the run finishes. You should see PUT attempts and any network errors there.

If you open egress and it still does not work, send the exec-daemon logs from one of those pods bc-2b906ba6-... or any recent one and we can dig deeper.

8

I had a allow list that did not include this url, so I’m gonna test it here. Thanks!!