Creating/Updating Agent OpenAPI Based Tools Broken On v0.8.1-rc2

[rio100]

What happened?

Upon upgrading from v0.8.0-rc4 to v0.8.1-rc2, the ability to create OpenAPI based actions for agents breaks. Agents can be created but OpenAPI based actions cannot be updated nor created. A 400 error occurs about the request failing.

The following does not appear on v0.8.0-rc4:

LibreChat | {"agent_id":"agent_vKvGhAlg30LUX4bArHH-x","level":"warn","message":"Domain mismatch detected: Domain mismatch: Client provided 'puppeteer-scrape', but spec uses 'puppeteer-scrape'","timestamp":"2025-12-15T17:52:17.832Z","userId":"68d377cbb879645c0735136a"}

Version Information

ghcr.io/danny-avila/librechat-dev latest 07c5c1919d99 4 days ago 1.61GB

    "Id": "sha256:07c5c1919d99e2fce0a46fd1278b4877346d8a94d1032dc35c61fafd72cf3297",
    "RepoTags": [
        "ghcr.io/danny-avila/librechat-dev:latest"

Steps to Reproduce

Step 1

Create agent

Step 2

Create or Update OpenAPI based Action

What browsers are you seeing the problem on?

FireFox

Firefox

Relevant log output

LibreChat          | {"agent_id":"agent_vKvGhAlg30LUX4bArHH-x","level":"warn","message":"Domain mismatch detected: Domain mismatch: Client provided 'puppeteer-scrape', but spec uses 'puppeteer-scrape'","timestamp":"2025-12-15T17:52:17.832Z","userId":"68d377cbb879645c0735136a"}

Screenshots

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

Thanks for the report. We can't help troubleshoot without some further details.

Please share as much of the OpenAPI spec as possible to help pinpoint the issue.

LibreChat | {"agent_id":"agent_vKvGhAlg30LUX4bArHH-x","level":"warn","message":"Domain mismatch detected: Domain mismatch: Client provided 'puppeteer-scrape', but spec uses 'puppeteer-scrape'","timestamp":"2025-12-15T17:52:17.832Z","userId":"68d377cbb879645c0735136a"}

Important observation: The log shows both values as identical ('puppeteer-scrape'), and this doesn't appear to be a valid domain format. Can you clarify what the actual server URL/domain is in your OpenAPI spec? If the actual domain is sensitive, please share a "fake" version that maintains the same format (e.g., if it's api.internal-company.com, share api.example-company.com or test-api.local).

There were necessary changes to OpenAPI Spec handling for security reasons in PR #10583:
#10583

Specifically, commit ba97460 implemented new domain validation logic that may be treating certain domain formats differently than before.

Please also try v0.8.1 (stable release) to see if this has been resolved since v0.8.1-rc2.

Please also review this discussion, which may be relevant: #10582

[rio100]

Just tried a fresh instance, no upgrade and the same issue. The following is the OpenAPI specs:
notes.txt

[rio100]

[rio100]

attached openapi specs for better visibility

[rio100]

@danny-avila ~ thanks Danny, great referencing!

My use case with Agent actions using OpenAPI specs are locally hosted on Docker. After digging into #10583 I noticed that docker host names do not make it through the logic criteria, so I tried the docker containers IP address and that worked.

However, if we can refactor to permit Docker host names as acceptable domains, I think there's some good there, but I would find a workaround if it jeopardizes the intent of #10583

Also, upon an upgrade to v0.8.1-rc2, previous agents that use Docker assigned host names will not process actions at all. The LLM just ignores it and hallucinates, including DeepSeek v3.2.

[rio100]

Just discovered the following regarding the URL used for OpenAPI specs on LC 0.8.1-rc2 and #10583 :

http://IpaddressOfDockerContainer:port <---- works
https://DockerContainerName:port <----- works
http://DockerContainerName:port <---- no go