@alesya-h Thanks for the PR!

This needs a bit of work but looks like a good start. Between this, gptel-gh (GitHub Copilot) and gptel-anthropic-oauth (Claude Pro/Max subscription support for gptel, not released publicly since it's against the Anthropic ToS), there are now three implementations of Oauth flow in gptel. Additionally gptel-bedrock (AWS Bedrock) is doing its own thing for fetching credentials. It will be difficult to maintain multiple Oauth flow implementations in the long run since they're all different. I'd like to consolidate the flows into a single code path before merging.

1. If you're interested in vibe-coding a single Oauth flow to use with all these sources, please go ahead (but make it a separate PR). I can share gptel-anthropic-oauth if required.
2. In this PR, I would prefer not to have both gptel-openai and gptel-openai-chatgpt backends, unless it can't be helped. Ideally it should be possible to specify something like (gptel-make-openai "OpenAI" :api-key 'oauth) to use the subscription. But this can be done at the very end -- developing this feature as a separate backend is easier.
3. gptel already provides a gptel--url-retrieve to simplify requests like asking for access tokens. gptel-gh uses it, this PR should too. If gptel--url-retrieve needs to be more flexible that can be added in this PR.

I'll take a closer look at the code when I can.

Hi. Thanks for looking into it. Regarding same vs different backend, the thing is it's not just oauth, it uses a different set of api endpoints that return data in a different format than normal completions api, and need to be converted. If it would be just auth flow I would totally agree, but given this, i am not so sure. Even the list of models available via regular openai api vs codex api is different.

I went looking for exactly this functionality and was happy to find this PR. I couldn't get it to work at first (now I suspect because I didn't have streaming on by default). Anyhow, after some back and forth with codex-cli I merged master with the branch (but I did not address the requests by karthink), if someone is also facing troubles they can take a peek at:

• https://github.com/bjodah/gptel/tree/chatgpt-subscription
• https://github.com/bjodah/gptel-test/tree/chatgpt-subscription

(although please consider my changes to be pure AI-slop, I've simply settled with "it works").
EDIT: actually tool calls weren't working, some more back-and-forth with codex/gpt-5.4@high gave:

• https://github.com/bjodah/gptel/tree/chatgpt-subscription-responses
• https://github.com/bjodah/gptel-test/tree/chatgpt-subscription-responses

EDIT2: tool calls works "most of the time" on the branch I linked to above, I get the intermittent error of the kind:
ChatGPT-Codex error: ((HTTP/2 400) invalid_request_error) No tool call found for function call output with call_id call_MiH8E4UWhK4ks1pKdST6mt8J.
...so it's definitely not a complete solution.

EDIT3: building on top of #1292, I have a branch which adds chatgpt-codex and deduplicates some oauth related functions from gptel-gh.el, I've tested the branch and so far everything seems to be working: bjodah#5

+1 to this! would be neat to use my chatgpt plus/pro subscription.

Lovely, just asked codex to patch my local gptel with this :-)

This is working great for me, just one problem. It always sets :stream t when it makes the request, which I think is correct as it seems the codex api doesn't support non-streaming requests.
But when we go to make a request with gptel-request or something with :stream nil, this openai backend sends the request with :stream t anyway, but gptel will be using the non-stream parser, and it will just silently fail, for example do something like:

(gptel-request
   "Say the days of the week in order."
   :callback
   (lambda (response info)
     (if (stringp response)
         (message "%s" response)
       (message "gptel-request failed: %s"
                (plist-get info :status)))))

and the callback is never called, GPT's explanation is:

But `gptel-request` still chooses the non-stream curl sentinel because the request info has no `:stream` flag. So the server returns an SSE/streaming response, while gptel tries to parse it as one complete JSON response.

Then this happens:

- `gptel-curl--sentinel` parses the response via `gptel-curl--parse-response` in `gptel-request.el:2808-2810`.
- The parser gets HTTP `200`, but no normal non-stream response text.
- Since `response` is nil and status is successful, this guard skips the callback entirely:

instead I think the openai backend should error and say it doesn't support non-streaming requests, when it is called with :stream nil

I did write a streaming callback and it's working great, I just think it should error rather than silently never calling the callback when you use it with :stream nil, I had a few confusing minutes figuring out what the problem was.

This PR also has an issue where it is not converting tool calls from the chat conversations to responses API format. I made a branch based on this at https://github.com/bo-tato/gptel/tree/codex-oauth which based this on the new gptel-openai-responses.el and sends tool calls correctly. That branch is not intended as a PR or anything, it's AI code I haven't read, just that it's working for me and maybe useful for others.

Added support for OpenAI/chatgpt/codex plus/pro subscription, whatever it's called now: 56e5b06.

It's not very robust yet, so please give it a good kicking if you can. Use gptel-make-openai-oauth, like (gptel-make-openai-oauth "OpenAI-plus") to make a backend.

@alesya-h Thank you for this PR. I'm closing it now as not planned (or required), but grabbing the various endpoints, IDs and auth results from this PR saved me a lot of work since this is a private OpenAI API and information about it is scattered across the web.

all good, thank you!