Nanobot repairs OAuth persistence inside Docker

HKUDS/nanobot issue #5444 is the inspected primary source: “Failed to ogin OpenAI via OAuth in Docker.” The related records below were inspected as supporting context rather than independent confirmation.

The facts

- HKUDS/nanobot issue #5444 was created 2026-08-19T13:34:41Z and was open at inspection; its title is “Failed to ogin OpenAI via OAuth in Docker.” - HKUDS/nanobot PR #5446 was created 2026-08-19T18:07:44Z and was open at inspection; its title is “fix(cli): route OpenAI Codex OAuth storage through nanobot's data dir.” - HKUDS/nanobot PR #5445 was created 2026-08-19T17:55:17Z and was open at inspection; its title is “fix(docker): persist OAuth client data.” - The repository reported 47184 stars, 721 open issues, default branch main, and last push 2026-08-19T17:53:48Z. - The latest tagged-release baseline checked was v0.3.0 published 2026-07-25T08:08:47Z.

What changed

HKUDS/nanobot issue #5444 reports: Bug Description I failed to ogin OpenAI via OAuth in Docker: Actually, I cannot find the path /home/nanobot/.local/share/oauth-cli-kit in the docker container. I am not sure if this is the reason why it returned permission denied. Steps to Reproduce 1. docker exec -it /bin/sh 2. exec shell command nanobot provider login openai-codex --set-main in the container 3. command returned permission denied like I posted above. Expected Behavior Use OAuth to login OpenAI successfully Relevant Logs nanobot Version 0.3.0 Python Version 3.12 Operating System Docker Channel / Platform Feishu (Lark) LLM Provider OpenAI Configuration (Optional) Additional Context _No response_

HKUDS/nanobot PR #5446 reports: Summary Routes OpenAI Codex OAuth token storage through nanobot's managed data directory instead of oauth-cli-kit's unmanaged platformdirs default. Problem nanobot provider login openai-codex can fail in Docker with: Even when writable, tokens saved to that location are lost when the container is replaced because it is outside the bind-mounted.nanobot volume. Root Cause _login_openai_codex() and _logout_openai_codex() in nanobot/cli/provider.py, together with _quick_start_oauth_login() and _quick_start_oauth_is_authenticated() in nanobot/cli/onboard.py, call oauth-cli-kit's token and login functions without an explicit storage or data_dir override. oauth-cli-kit therefore falls back to platformdirs.user_data_dir(), which resolves to a path that Docker's entrypoint does not create, manage, persist, or assign to the nanobot user. Other nanobot OAuth integrations already avoid this problem by storing their authentication data under get_data_dir(). Changes Updated nanobot/cli/provider.py so OpenAI Codex login and logout use FileTokenStorage rooted in nanobot's managed data directory. Added a shared _openai_codex_oauth_storage() helper in nanobot/cli/onboard.py and used it for both Quick Start OAuth call sites. Extended the existing typed OAuth boundaries with the required storage and data_dir parameters. Updated affected mocks and added focused regression tests confirming that OpenAI Codex OAuth storage resolves under nanobot's managed data directory. Testing [x] New regression tests fail on unmodified main and pass with the fix. [x] Focused test files: 283 passed. [x] Two pre-existing, unrelated dulwich failures reproduced identically on unmodified main. [x] ruff check on

HKUDS/nanobot PR #5445 reports: Summary direct XDG application data to the mounted Nanobot instance directory in the Docker image keep OAuth credentials writable after the entrypoint drops to the non-root nanobot user document that container-created OAuth credentials persist across replacement Root cause oauth-cli-kit stores its token file under the XDG data directory. The image previously left that at $HOME/.local/share, outside the directory mounted and ownership-fixed by the container entrypoint. Docker deployments could therefore fail to write the token or lose it when the container was replaced. Validation git diff --check Docker image build could not be run locally because the Docker daemon is unavailable in this environment. Fixes #5444

Why it matters

Container authentication is not complete when the browser callback succeeds; it is complete when the runtime can read the same durable state after restart. Split paths create convincing false success. The operator test is whether the system remains bounded and its receipts still describe the action after failure, retry or restart.

Current

The primary record was open when captured on 2026-08-20. The tagged-release baseline was v0.3.0 published 2026-07-25T08:08:47Z. Repository metadata, full source bodies, current pull requests and issues, releases, Google News, Hacker News, Lobsters, Metamesh and the rendered ClawCharts row were inspected. ClawCharts selected the subject; it did not prove the claim.

Evidence

The primary URL is https://github.com/HKUDS/nanobot/issues/5444. Supporting records are https://github.com/HKUDS/nanobot/pull/5446 and https://github.com/HKUDS/nanobot/pull/5445. Source bodies, timestamps and states are preserved in the daily evidence bundle. Test counts and reproductions remain attributed to their authors unless identified as independently rerun.

Source boundary

Open work is described as open, closed work as closed, and operator reports as reports. A pull request is evidence of proposed or reviewed direction, not proof of a shipped release. Search residue, package mirrors and historically published source spines were excluded.

Operator take

Put OAuth client and token state under one mounted data directory, verify readback after container restart, and never print credential values during diagnosis. Preserve a before-state receipt, make the smallest reversible change, and verify the original failure independently.

Caveat

Public project records are mutable. Status, scope and evidence can change after publication. This brief records the inspected state and does not authorize changes to a reader’s deployment.

Source inspected; source state, environment and release boundary remain explicit.