Skip to content

OpenAI/ChatGPT OAuth is not a viable NemoClaw provider path without manual host-side OpenClaw gateway bridging #1793

Description

@coco779

Summary

On nemoclaw v0.0.13, I could not complete a clean/supported setup that uses OpenAI/ChatGPT OAuth as NemoClaw's inference backend, even though the overall NemoClaw/OpenClaw stack strongly suggests this should be possible in principle.

What ultimately worked was a manual workaround:

  1. install the host openclaw CLI separately
  2. complete OpenAI OAuth there
  3. expose host OpenClaw as an OpenAI-compatible gateway
  4. point OpenShell/NemoClaw's compatible-endpoint provider at that host gateway

So the containerized NemoClaw/OpenShell/OpenClaw runtime can work with OpenAI OAuth indirectly, but there does not appear to be a first-class NemoClaw path for it.

Environment

  • OS: Linux Mint 22.3
  • nemoclaw v0.0.13
  • openshell 0.0.26
  • Host openclaw 2026.4.10
  • Docker installed and working
  • No GPU in this VM

What I expected

Because NemoClaw bundles OpenClaw/OpenShell and advertises OpenClaw-based secure sandboxing, I expected one of these to work cleanly:

  • a native NemoClaw/OpenShell provider option for OpenClaw/OpenAI OAuth
  • or a documented way to import/use existing OpenClaw auth profiles
  • or a supported way to route NemoClaw inference through an OpenClaw gateway without custom patching and manual bridge setup

What actually happened

1. NemoClaw onboarding does not offer a clean OpenAI OAuth path

During nemoclaw onboard, the relevant provider choices are API-oriented (OpenAI, Other OpenAI-compatible endpoint, etc.).

That does not appear to support native OpenAI/ChatGPT OAuth directly.

2. Host OpenClaw OAuth worked only after local patching

I had to install the host openclaw CLI separately and use its OAuth flow.

That initially failed because the shipped OpenClaw OAuth flow requested invalid scopes. I filed that upstream here:

After patching the installed OpenClaw CLI locally, OAuth succeeded.

3. NemoClaw/OpenShell could only use OAuth indirectly via a manual bridge

To make NemoClaw actually work with that OAuth-backed model path, I had to:

  • run host openclaw gateway
  • configure it with token auth and non-loopback bind
  • disable its control UI for bridge use
  • point OpenShell provider compatible-endpoint at http://host.docker.internal:18889/v1
  • raise OpenShell inference timeout from 60s to 180s

Only after that did the sandboxed NemoClaw path succeed via:

  • host gateway: http://127.0.0.1:18889/v1/chat/completions
  • sandbox route: https://inference.local/v1/chat/completions

Why I think this is a NemoClaw issue too

The OpenClaw scope bug is upstream to OpenClaw, but NemoClaw still seems to have a product/integration gap here:

  • no first-class OpenAI OAuth onboarding path
  • no documented host OpenClaw gateway bridge workflow
  • no import/reuse of host OpenClaw auth state
  • default OpenShell inference timeout was too short for this routed OAuth-backed path

So today, a user trying to use ChatGPT/OpenAI OAuth with NemoClaw ends up in an awkward place where:

  • OpenClaw can authenticate
  • NemoClaw can sandbox
  • but the official path between those two is missing or undocumented

Reproduction (high level)

  1. Install Docker and nemoclaw
  2. Run nemoclaw onboard
  3. Try to choose a provider path that uses OpenAI/ChatGPT OAuth
  4. Observe there is no clean first-class option
  5. Install host openclaw separately and complete OAuth there
  6. Try to make NemoClaw use that auth state directly
  7. Observe that this does not work without a manual OpenAI-compatible bridge/gateway setup

Workaround that eventually worked

  • install host openclaw
  • patch host OpenClaw OAuth scopes locally so login succeeds
  • run host OpenClaw as an OpenAI-compatible gateway
  • configure NemoClaw/OpenShell compatible-endpoint to use that gateway
  • increase OpenShell inference timeout to 180s

Request

Please consider one or more of these improvements:

  1. Add a first-class NemoClaw/OpenShell path for OpenClaw/OpenAI OAuth.
  2. Document a supported bridge workflow using host OpenClaw gateway.
  3. Support importing or referencing host OpenClaw auth profiles from NemoClaw/OpenShell.
  4. Revisit default routed inference timeouts for slower OAuth-backed/gateway-backed providers.
  5. Clarify in docs which provider/auth combinations are officially supported today.

Notes

I can provide more exact local config details if helpful, but I wanted to keep this report focused on the user-visible integration gap rather than my local patches.

Activity

  1. coco779 commented on Apr 12, 2026

    @coco779
    Author

    A small follow-up with the upstream dependency and the exact architecture that ended up working.

    Upstream OpenClaw OAuth bug:

    That issue covers the invalid OAuth scopes I hit in the standalone host openclaw CLI. After patching that locally, OAuth login succeeded.

    The working architecture on my side is:

    • host openclaw CLI handles OpenAI/ChatGPT OAuth
    • host openclaw gateway exposes an OpenAI-compatible API with token auth
    • OpenShell compatible-endpoint points to that host gateway
    • NemoClaw sandbox uses OpenShell inference routing via https://inference.local
    • sandboxed/containerized OpenClaw then talks to the host gateway indirectly through OpenShell

    In concrete terms, it ended up looking like:

    • host gateway: http://host.docker.internal:18889/v1
    • OpenShell provider: compatible-endpoint
    • OpenShell model: openclaw/default
    • OpenShell timeout: 180s

    So the key gap is not that OAuth is impossible in the stack, but that today it required a manual host-side OpenClaw gateway bridge rather than a first-class NemoClaw/OpenShell flow.

  2. wscurran commented on Apr 13, 2026

    @wscurran
    Contributor

    ✨ Thanks for submitting this issue, which proposes adding support for OpenAI/ChatGPT OAuth as a NemoClaw provider.

  3. added
    area: inferenceInference routing, serving, model selection, or outputs
    area: providersInference provider integrations and provider behavior
    enhancementNew capability or improvement request
    and removed on Jun 3, 2026
  4. latenighthackathon commented on Jun 25, 2026

    @latenighthackathon
    Collaborator

    Hi @coco779, thank you for raising this. You filed this on v0.0.13, which is around 55 releases behind the current v0.0.68, so a great deal of the onboarding and provider flow has changed since then. Could you give it a try on the latest version and confirm whether this is still an issue for you? Closing for now, but if you are still running into issues on the latest version, please feel free to create a new issue, cheers!

  5. snarkipus commented on Jul 3, 2026

    @snarkipus

    This issue is downstream of NVIDIA/OpenShell#1306 which remains open. Unless NemoClaw implemented OAuth token management external to OpenShell, this should probably remain open. @latenighthackathon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: inferenceInference routing, serving, model selection, or outputsarea: providersInference provider integrations and provider behaviorintegration: openclawOpenClaw integration behaviorprovider: openaiOpenAI API or OpenAI-compatible provider behavior

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions