docs/oauth-callback-port-source-check-2026-09-26.md
Rama main · réplica de lectura del repositorio original.
# OAuth callback-port source check
Review date: 2026-09-26
**Historical implementation review:** its callback-port observations concern
the former Codex CLI login and credential-copy bridge, not current local SIWC
registration. See the
[2026-10-04 source check](openai-source-check-2026-10-04.md) for current flow
evidence and limits.
This review covers Relmio 0.17.5. Before the official Codex browser login for
an OpenAI OAuth bridge, the wizard probes both `127.0.0.1:1455` and `[::1]:1455`
to see whether a TCP connection is accepted. The probe does not identify the
listener or establish that it can receive the browser callback. The release
also adds troubleshooting guidance for the reported sign-in page and MCP
`Transport closed` errors. This is a local reliability change. It is not a
legal opinion and does not establish account entitlement.
## Current official sources
- [Sign in with ChatGPT](https://help.openai.com/en/articles/20001410-sign-in-with-chatgpt)
- [Codex authentication](https://learn.chatgpt.com/docs/auth)
- [OpenAI Terms of Use](https://openai.com/policies/row-terms-of-use/)
- [OpenAI Services Agreement](https://openai.com/policies/services-agreement/)
- [OpenAI Privacy Policy](https://openai.com/policies/privacy-policy/)
The Help Center article and Codex authentication page were retrieved directly
on the review date. In the initial retrieval, the three policy pages returned
HTTP 403 to command-line retrieval and were not re-read; the then-most-recent
recorded review was dated 2026-09-21. A dated follow-up below records successful
policy retrieval later on 2026-09-26. The original 403 result is retained here
as historical context, not a current access limitation.
## Findings
The Sign in with ChatGPT article describes identity sign-in for supported
external applications. The application receives name, email address, and
profile picture, and any additional access needs a separate permission
request. That identity-only description does not match or authorize Relmio's
third-party ChatGPT/Codex compatibility transport. This release does not
change that assessment.
The Codex authentication page says that `codex login` opens a browser, which
then returns credentials to Codex. It names the default local callback server
as `localhost:1455`. It lists "your local networking configuration blocks the
localhost callback" as a case where the browser flow may not work. It also
documents `cli_auth_credentials_store = "file"`, which writes `auth.json` under
`CODEX_HOME`. Admins can enforce that setting so that users cannot override
it. Relmio's preflight matches this documented callback design and does not
change the login command, its arguments, or its credential store.
## Relmio data flow for this release
- **Reads:** unchanged. The new preflight opens a TCP connection to
`127.0.0.1:1455` and `[::1]:1455` on the user's own computer, sends no bytes,
and closes it at once. It reads only whether a connection was accepted.
- **Stores:** unchanged. The preflight stores nothing. If a listener is found,
Relmio does not create the pending sign-in directory.
- **Transmits:** unchanged. The preflight never leaves the loopback interface.
The official Codex login still sends the browser sign-in to OpenAI. Relmio
still seeds the resulting credential only into its owned bridge volume or,
for VPS bridges, uploads it after explicit confirmation.
- **Logs:** unchanged. The wizard shows a fixed message that names port `1455`.
Relmio does not log the other process's identity, prompts, or tokens.
- **OAuth scopes and permissions:** Relmio does not supply an explicit OAuth
scope list or inspect the grant. The pinned Codex CLI's requested and granted
scopes remain unknown. This callback-port change adds no known permission.
- **Recipients:** unchanged. OpenAI receives the browser sign-in. The user's
own n8n bridge receives the resulting credential.
## Unknowns and limits
- Whether OpenAI permits this exact compatibility transport for the account
and use case remains unresolved.
- In the initial retrieval, the Terms, Services Agreement, and Privacy Policy
returned HTTP 403 to command-line retrieval and were not re-read. The
successful follow-up retrieval later on 2026-09-26 is recorded below; the
initial 403 remains historical context.
- If an admin enforces a non-file `cli_auth_credentials_store`, the file-based
login that Relmio requests may be overridden. This release does not change
or detect that behavior.
- A listener that starts after the preflight could interfere with the callback,
but the preflight does not establish which process received a browser
callback. The pinned Codex source and attribution limits are recorded in the
2026-09-26 follow-up below.
## Follow-up — 2026-09-26
### Pinned Codex callback behavior
The pinned `@openai/codex@0.154.0` source was reviewed at immutable commit
[`6b9826e3aa83b1a5947db50f4332cb9c65f1b340`](https://github.com/openai/codex/blob/6b9826e3aa83b1a5947db50f4332cb9c65f1b340/codex-rs/login/src/server.rs).
It defines port `1455` as the default and `1457` as a registered fallback,
binds the callback server to IPv4 loopback, and constructs the browser callback
URL from the port actually bound. On a collision at the default port, the CLI
may send a local `GET /cancel`, retry binding, and use the fallback. Therefore
a listener at `1455` does not by itself prove that Codex failed to bind or that
the listener received a callback.
The wording “Signed in to ChatGPT” / “This sign-in request expired” does not
identify its originating application or prove callback delivery to another
process. A competing localhost listener is a plausible interference path, not
an observed cause in the reported case. No screenshot or callback receipt was
independently observed in this source review. Do not share callback query
strings, authorization codes, `state` values, tokens, or full authentication
URLs when seeking help.
### Successful policy retrieval
Later on 2026-09-26, the following official pages were retrieved successfully;
this updates the initial retrieval limitation above without erasing its
historical 403 result:
- [OpenAI Terms of Use](https://openai.com/policies/terms-of-use/) (canonical
ROW Terms, published and effective 2026-01-01): restrictions include
credential sharing, programmatic extraction, circumvention, and bypassing
safeguards.
- [OpenAI Services Agreement](https://openai.com/policies/services-agreement/)
(updated 2025-12-01; effective 2026-01-01): covers specified business and
developer services, but does not expressly approve this third-party
subscription-credential bridge.
- [Privacy Policy](https://openai.com/policies/privacy-policy/) (updated
2026-07-30; retrieval returned the canonical
[services communications privacy policy](https://openai.com/policies/services-communications-privacy-policy/)):
describes account/content/log data and listed recipient categories. This
source review does not establish which parties received a particular user's
data.
- [Codex authentication](https://learn.chatgpt.com/docs/auth) documents the
host CLI's browser login and credential file behavior; it does not provide
approval for Relmio's n8n-compatible transport.
The identity article's supported-app identity sign-in is distinct from the
host Codex CLI credential flow. Relmio's explicit confirmation is permission
for its same-owner deployment copy, not a provider-delegated grant. The
requested/granted scopes, account entitlement, and permission for this exact
compatibility use remain unknown. This follow-up and the callback reliability
changes do not establish OpenAI approval or broaden any scope.
Public social statements and private maintainer correspondence mentioned in
`docs/security.md` were not used as permission evidence in this follow-up. They
do not establish account-specific scopes, entitlement, or permission for this
bridge.
### Capability and authentication separation
Also retrieved on 2026-09-26:
- [Codex models](https://learn.chatgpt.com/docs/models): availability depends
on rollout, sign-in method, client, plan, and workspace settings. Selecting
a model does not grant access. This review did not establish any particular
account's model entitlement or prove a TTS capability.
- [OpenAI API authentication](https://developers.openai.com/api/reference/overview#authentication):
the documented API credentials are API keys or short-lived workload-identity
tokens. This is distinct from Codex subscription sign-in and is not approval
to repurpose a Codex credential as a general API credential.
The accompanying managed local-model flow uses a private Ollama runtime and
the reviewed Qwen catalog, not an OpenAI credential or an OpenAI-hosted model.
It adds no OpenAI OAuth scope or cloud fallback. Its inference readiness does
not establish n8n tool reliability, AI Assistant eligibility, or TTS support.
The separate [local-model data-flow and capability limits](./local-models.md)
describe registry downloads, unauthenticated trusted-network access, model
cache retention, and n8n/host logging.
## Follow-up — SSH agent and model-only sudo — 2026-09-26
This is a dated source/data-flow review of the cloud-host access continuation,
not a release certification or legal opinion. The source reviewer inspected
the previous SSH implementation and the new shared contract while integration
was in progress. Subsequent implementation-owner handoffs describe the new
transport and model-only scope. Integration verification on 2026-09-26 passed
1,216 root tests with 16 platform skips and 73 web tests. Actual browser
scenarios against injected remote services rejected credential routes on a
model-only session and rejected stale cross-tab identities. A separate real
loopback SSH handshake verified agent signatures and host-key rejection,
with administrative probe responses explicitly emulated. These checks do
not establish live VPS sudo, native Windows agent, Linux Docker or provider
deployment success, and do not certify provider permission or Terms compliance.
### Current official sources and distinctions
The reviewer retrieved the following first-party sources on 2026-09-26:
- [Sign in with ChatGPT](https://help.openai.com/en/articles/20001410-sign-in-with-chatgpt)
(displayed “Updated: 2 days ago”): participating-app identity sign-in shares
name, email and profile picture; it does not independently share files or
tokens. Additional access needs separate user authorization, even where an
organization has approved the application.
- [Codex authentication](https://developers.openai.com/codex/auth/), resolving
to [the current authentication guide](https://learn.chatgpt.com/docs/auth):
documents browser credentials returning to Codex, file/keyring storage,
`CODEX_HOME/auth.json`, administrator settings and trusted headless-machine
or container credential-cache copying. That documented Codex pattern is
not blanket approval for a third-party n8n-compatible credential bridge.
- [Codex models](https://developers.openai.com/codex/models/), resolving to
[the current model guide](https://learn.chatgpt.com/docs/models): account,
client, rollout, plan and workspace controls determine availability.
- [API authentication](https://developers.openai.com/api/reference/overview#authentication)
documents API keys or short-lived workload-identity tokens, not a grant to
turn a Codex subscription credential into a general OpenAI API credential.
- [Text-to-speech](https://developers.openai.com/api/docs/guides/text-to-speech)
documents a separate Audio API capability and AI-generated-voice disclosure.
It does not establish TTS support through this bridge.
- [Terms of Use](https://openai.com/policies/terms-of-use/), canonical
[ROW terms](https://openai.com/policies/row-terms-of-use/) (published/effective
2026-01-01), and [Services Agreement](https://openai.com/policies/services-agreement/)
(updated 2025-12-01, effective 2026-01-01): account/credential restrictions,
documented-use requirements and anti-circumvention provisions remain
applicable as determined by the user's region, account and agreement.
Neither page expressly approves this exact third-party subscription bridge.
- [Service Terms](https://openai.com/policies/service-terms/) (updated
2026-09-21): documented API use, Codex/code-generation and ChatGPT Voice
Output are distinct subjects, not interchangeable grants.
- [Privacy Policy](https://openai.com/policies/privacy-policy/), returning the
[services communications privacy policy](https://openai.com/policies/services-communications-privacy-policy/)
(updated 2026-07-30): describes account/content/log/usage data and recipient
categories. Business-service data can instead be governed by customer
agreements. This does not identify a particular user's actual downstream
recipients, retention or training settings.
**Identity, delegated permission and model/TTS capability are three different
checks.** Relmio obtains a Codex credential file and copies its complete
validated JSON for the user's private bridge; that does not match the identity
article's identity-only data release. A successful login, local install
confirmation or SSH-agent connection is not OpenAI permission for this use.
The bridge remains unofficial, private and policy-uncertain. Its audio routes
remain unsupported; local Ollama readiness does not establish provider
entitlement, Assistant capability or reliable tool calling.
### Reads, stores, transmits and logs
- **SSH authentication:** the local browser/Relmio process handles host, port,
username, confirmed host fingerprint and the explicitly chosen password or
agent method. The local SSH library requests public identities and signatures
from the supported local agent; the private key remains in its agent/key
store. Authentication public-key/signature data still travels to the remote
SSH server. This is not a claim that “no authentication data is transmitted.”
No browser private-key/passphrase input, key-file reading or agent forwarding
belongs to the new transport contract.
- **Session/capability state:** Relmio holds the authenticated connection and
safe identity in process memory. Capability status reports only safe
configured/untested/unavailable information, not socket paths or browser key
lists. Clearing the browser password/request field is not proof that every
internal library copy is immediately erased from memory.
- **Existing credential flow:** the pinned Codex CLI uses a protected pending
file store and Relmio validates access/ID/refresh-token fields before
promoting the complete JSON to `~/.n8n-openai-oauth/auth.json` by default
(overridable through its existing home setting). For an explicitly confirmed
direct-root VPS bridge operation, the complete validated file is copied by
SFTP to `/docker/n8n-openai-oauth/auth/auth.json`, mode `0600`, and mounted
into the sidecar at `/home/node/.codex`. The pinned third-party
`openai-oauth` package consumes it. Agent authentication does not remove or
broaden this credential-copy disclosure.
- **Model-only sudo:** the implementation contract confines this context to
model operations and shared discovery, denying OAuth bridge, Assistant and
SuperGrok VPS operations before credential reads/service calls/uploads.
Model stdin uploads contain packaged runtime assets and managed metadata
such as model/install IDs, resource identities, measurements and hashes,
not provider/Assistant credentials. That metadata is non-secret, not
necessarily appropriate for public disclosure. Direct-root credential
transfers retain their SFTP path; they are not moved into sudo stdin.
- **Docker client build state:** the later integration uses bounded silent
current/default selector attestation, not `docker buildx inspect`, which can
initialize home state and expose nodegroup secrets. After final confirmation,
build-capable model, SuperGrok and OAuth actions create temporary root-only
Buildx client state in their respective owned operation locks. The exact
[reviewed state paths](reference.md#vps-authentication-and-privilege) are
deployment metadata, not an OAuth grant. State-management code does not copy,
move or print registry credentials; normal Docker registry authentication is
separate from that statement. The OAuth build-context allowlist excludes
credential files, sibling installations and temporary state. Verified cleanup
removes only owned temporary state; uncertainty can retain a lock and partial
tree for administrator inspection. These changes add no known OpenAI scope
or model/TTS capability. Source inspection and adapted POSIX filesystem
checks are not proof of native privileged Linux/Compose/provider execution.
- **Inference/downloads:** the model runtime uses `OLLAMA_NO_CLOUD=1` on the
selected eligible private Docker network. The acquisition helper submits a
fixed inference probe; subsequent n8n workflow data goes to that Ollama
runtime. Image/model registries receive setup/download requests. Disabling
cloud models does not block registry egress or n8n tools contacting their
own external services.
- **Logs:** Relmio uses bounded subprocess/SSH output and sanitized error/status
projections; model runtime/helper logs are bounded. This does not control
remote sudo/sshd audit recording, n8n execution history, host/provider
logging, backups, third-party runtime internals or Codex diagnostic files.
Current Codex docs mention login diagnostics; their precise behavior in the
pinned CLI was not audited here. Sudo I/O recording is why credential-bearing
operations are excluded from model-only scope. No “nothing is logged”
guarantee is made.
Identifiable processing components are the user's browser/local Relmio process,
local SSH agent, selected remote SSH server and administrator-controlled
storage/Docker runtime, n8n, the selected local-model service, and—when the
separate credential bridge is used—the sidecar/third-party package and OpenAI.
OpenAI receives browser sign-in and supported provider-bound bridge requests;
npm and image/model registries receive relevant installation/download requests.
Exact registry/CDN chains were not traced. Other trusted-network containers
are potential callers of the unauthenticated model API, not proven recipients
of every prompt. Privileged host/provider administrators and logging systems
remain trust/exposure boundaries.
### Scopes, unknowns and acceptance limits
Relmio supplies no explicit scope list in the inspected Codex login command
and does not inspect requested or granted scopes. Valid token fields are not
scope validation. This SSH change requests no known additional OpenAI scope;
it does not prove an unchanged or approved provider grant. Account/workspace
restrictions, applicable contractual permission and actual scopes remain
unknown. No provider call or entitlement test was performed in this review.
Integration checks exercised model-only credential-route rejection,
asynchronous identity replacement and the separate direct-root/SFTP boundary.
The source review itself is not runtime evidence; actual Linux/provider
acceptance remains separate. Private maintainer correspondence, identity
sign-in success and user deployment consent cannot substitute for provider
permission. See [Security](security.md), [Hosting compatibility](hosting-compatibility.md)
and [Local models](local-models.md) for the public operational boundaries.