internal/core/cli.FallbackCLIDirs (cli.go:13-20) probes /usr/local/bin first and $HOME/.local/bin fourth. TestFetchToken_FallbackDirScan (internal/core/dbxauth/dbxauth_test.go:195-224) sets PATH="" and HOME=<tmpdir> and plants a mock CLI at $HOME/.local/bin/databricks — but the scan reaches the real /usr/local/bin/databricks first. That real binary then runs with HOME pointed at an empty temp dir, finds no ~/.databrickscfg, and exits 1.
Repro:
HOME=/tmp/fakehome PATH="" /usr/local/bin/databricks auth token --profile DEFAULT
# Error: the command is being run in a non-interactive environment, please specify a host
This fails on essentially every developer machine that has the Databricks CLI installed — i.e. most users of this tool. It passes in CI only because ubuntu-latest has no Databricks CLI, so the defect is invisible to the pipeline.
Note this is not an authentication problem — the CLI is authenticated on the affected host. Authenticating differently would not fix it; if anything an env-var-authenticated host returns a real token and fails the tok != "tok-fallback" assertion instead.
Suggested fix: add an injection seam for the scan roots — e.g. a package-level var fallbackDirs = FallbackCLIDirs in internal/core/cli with a test-only setter, following the codebase's existing var execCommand = exec.Command / var getuid = os.Getuid override pattern — so the test can scope the scan to its temp HOME instead of racing the host's real install.
Not fixed in #238 (the Responses-rewriter removal) — unrelated surface, kept out to preserve a one-operation revert.
internal/core/cli.FallbackCLIDirs(cli.go:13-20) probes/usr/local/binfirst and$HOME/.local/binfourth.TestFetchToken_FallbackDirScan(internal/core/dbxauth/dbxauth_test.go:195-224) setsPATH=""andHOME=<tmpdir>and plants a mock CLI at$HOME/.local/bin/databricks— but the scan reaches the real/usr/local/bin/databricksfirst. That real binary then runs withHOMEpointed at an empty temp dir, finds no~/.databrickscfg, and exits 1.Repro:
This fails on essentially every developer machine that has the Databricks CLI installed — i.e. most users of this tool. It passes in CI only because
ubuntu-latesthas no Databricks CLI, so the defect is invisible to the pipeline.Note this is not an authentication problem — the CLI is authenticated on the affected host. Authenticating differently would not fix it; if anything an env-var-authenticated host returns a real token and fails the
tok != "tok-fallback"assertion instead.Suggested fix: add an injection seam for the scan roots — e.g. a package-level
var fallbackDirs = FallbackCLIDirsininternal/core/cliwith a test-only setter, following the codebase's existingvar execCommand = exec.Command/var getuid = os.Getuidoverride pattern — so the test can scope the scan to its tempHOMEinstead of racing the host's real install.Not fixed in #238 (the Responses-rewriter removal) — unrelated surface, kept out to preserve a one-operation revert.