openaiFileIdRefs Not Auto-Populated in Action Call (createMap) – Publishing Fails

GPT builders Plugins / Actions builders
1

We are experiencing an issue when calling a custom Action (createMap) that requires openaiFileIdRefs.

Expected Behavior

According to the documentation:
https://developers.openai.com/api/docs/actions/sending-files

When providing a local file path (e.g. /mnt/data/output.html) in the Action call, the runtime should automatically transform it into a file reference object:

{
  "name": "...",
  "id": "...",
  "mime_type": "...",
  "download_link": "..."
}

This object should be injected into openaiFileIdRefs.

Actual Behavior

  1. When calling:
"openaiFileIdRefs": []

The API correctly fails schema validation:

[] should be non-empty
  1. When calling:
"openaiFileIdRefs": ["/mnt/data/output.html"]

The request fails with:

AssertionError

The runtime does not:

  • Auto-populate file metadata

  • Transform the local path into a file object

  • Inject the required name, id, mime_type, download_link

Environment Details

  • File exists in sandbox: /mnt/data/output.html

  • File ID is generated (visible in system logs)

  • Action schema requires:

openaiFileIdRefs: {
  type: "array",
  minItems: 1,
  items: {
    name: string,
    id: string,
    mime_type: string,
    download_link: string
  }
}

The Action cannot succeed because the runtime does not bind the file reference into the payload.

Summary

The publishing capability itself is functional, but:

  • File reference injection into openaiFileIdRefs is not working.

  • The runtime is not transforming sandbox paths into file objects as described in the documentation.

  • This blocks all file-based Action calls.

Please advise whether:

  • The transformation behavior has changed,

  • A different payload format is now required,

  • Or this is a regression in the Actions runtime.

2

Hey @Eduard_Budacu

Appreciate you flagging this. We’re going to take a closer look and dig into what might be causing it. We’ll report back as soon as we know more.

3

Any updates on this issue? I’m encountering the same problem. Any guidance would be much appreciated

4

Thanks for reporting this. We’ve confirmed a known issue affecting GPT Action file references in some file-upload/download flows, which can prevent publishing from completing. If this is affecting your workspace, please email support@openai.com with the details and include the Case ID or subject line so we can investigate your specific setup privately.

5

Thanks for flagging this. We took another look at this issue. At the moment, the best path is to open a support case with a fresh repro so the team can review current evidence end to end. If you do that, please include:

  • the GPT or Action schema you’re testing
  • the model you’re using
  • the approximate UTC time of a failing run
  • a conversation link or screen recording
  • a HAR or request details if you have them

As a temporary workaround, if your workflow allows it, try avoiding the generated file-reference path and instead pass the output directly in the action payload or use a standard uploaded-file flow.

Once a new support case is opened with current evidence, the team can verify whether this is a regression of an older fix or a separate issue.

6

I’m seeing a related openaiFileIdRefs issue.

In my GPT Action call, the file object is populated, but download_link is coming through as a local sandbox path:

/mnt/data/uploaded-file.pdf

instead of a temporary signed URL like:

https://files.oaiusercontent.com/...

Since the action backend is external, it can’t access /mnt/data/..., so it receives the file metadata but cannot download the uploaded PDF.

Expected: openaiFileIdRefs[].download_link should be an externally fetchable signed HTTPS URL.

Is this the same issue, or is there a schema/config change needed to force signed file URLs?

7

Hi there and thanks so much for flagging. Sorry to read this is not solved for you. The best path is to open a support case with a fresh repro so the team can review current evidence end to end. If you do that, please include:

  • the GPT or Action schema you’re testing
  • the model you’re using
  • the approximate UTC time of a failing run
  • a conversation link or screen recording
  • a HAR or request details if you have them

As a temporary workaround, if your workflow allows it, try avoiding the generated file-reference path and instead pass the output directly in the action payload or use a standard uploaded-file flow.

Once a new support case is opened with current evidence, please share the case number here and we'll follow up with you on that thread.