Force token refresh in the auth-token apiKeyHelper#191
Conversation
`ucode auth-token` is the command Claude Code's apiKeyHelper (and Codex's auth command) re-invokes every 15 min via CLAUDE_CODE_API_KEY_HELPER_TTL_MS. It called `databricks auth token` without --force-refresh, so the token was only renewed when the CLI independently judged the cached token "close to expiry" — which can lapse between invocations, killing a long session at the original token's ~1h expiry. Pass force_refresh=True so each refresh cycle hands back a token with a full fresh lifetime, matching the force_refresh=True already used by the gemini/opencode/copilot/pi background refreshers. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR fixes long-running agent sessions (Claude Code/Codex) failing at ~1 hour due to Databricks OAuth token expiry by forcing a refresh on every ucode auth-token helper invocation, bypassing the Databricks CLI’s “close to expiry” heuristic.
Changes:
- Update
ucode auth-tokento callget_databricks_token(..., force_refresh=True)every time. - Add CLI-level test coverage ensuring
auth-tokenforwardsforce_refresh=True. - Add Databricks argv-forwarding tests verifying
--force-refreshis appended only when requested.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/ucode/cli.py | Forces refresh in auth-token helper to prevent token-expiry session drops. |
| tests/test_cli.py | Verifies auth-token forwards force_refresh=True and keeps stdout clean. |
| tests/test_databricks.py | Verifies get_databricks_token forwards --force-refresh appropriately. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Mirror the real get_databricks_token signature (force_refresh is keyword-only) in the --use-pat test lambdas, so the test would fail if the production call site ever passed force_refresh positionally. Addresses PR review feedback. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Thanks — good catch. Addressed in 08bd1d4: the three |
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
…spaces - Strip DATABRICKS_BEARER in the _fake_databricks helper: get_databricks_token short-circuits on it, so a leaked CI/developer bearer would bypass the fake CLI shim and make the whole TestGetDatabricksToken class's assertions meaningless. - Quote the argv-log redirection target in the fake shim so tests don't break when the temp path contains spaces. Addresses PR review feedback. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Pushed 54b4432 on top of the accepted quoting suggestion:
All 216 tests in |
Problem
Long-running Claude Code / Codex sessions die when the original Databricks OAuth token expires (~1h), even though the
apiKeyHelperis configured to refresh every 15 min viaCLAUDE_CODE_API_KEY_HELPER_TTL_MS: 900000.Root cause
ucode auth-tokenis the command Claude Code'sapiKeyHelper(and Codex's auth command) re-invokes on that 15-min interval. It calledget_databricks_token(...)withoutforce_refresh, so the underlyingdatabricks auth tokenonly renewed the token when the CLI independently judged the cached token "close to expiry":That heuristic can lapse between helper invocations, so the session dies at the original token's expiry. Notably, this is inconsistent with the gemini/opencode/copilot/pi agents, whose background refreshers already pass
force_refresh=True.Fix
Pass
force_refresh=Truefrom theauth-tokenhelper so each refresh cycle bypasses the expiry heuristic and hands back a token with a full fresh lifetime.Tests
tests/test_cli.py— theauth-tokencommand forwardsforce_refresh=True.tests/test_databricks.py—--force-refreshis (and by default isn't) forwarded to the realdatabricks auth tokenargv.Full suite passes (
853 passed); the only failures are two pre-existing network-dependent e2e tests that also fail on cleanmain.Note for reviewers
PR #137 (Windows support) touches this same auth code and is stale against #177 — the two will conflict.
🤖 Generated with Claude Code