Skip to content

Windows: ucode claude fails with apiKeyHelper POSIX shell error #116

@Stevenac-code

Description

@Stevenac-code

Windows: ucode claude fails with apiKeyHelper POSIX shell error

Summary

On Windows, ucode claude can fail after Databricks auth succeeds with:

apiKeyHelper failed: exited 1: No se esperaba -n en este momento.

The failure appears to come from the generated Databricks helper command being POSIX shell syntax, which is not valid in the Windows shell context used by Claude Code.

Evidence

  • Uploaded evidence: screenshot 1 shows ucode claude failing on Windows, and screenshot 2 shows the ucode configure traceback leading to the Databricks setup path.

  • The terminal output shows ucode claude reaching Databricks auth successfully and then failing when Claude Code starts.

  • The exact error shown is:

    apiKeyHelper failed: exited 1: No se esperaba -n en este momento.

  • A related report is visible in GitHub issue ucode configure fails without existing Databricks auth profile #54, where ucode configure fails when no Databricks auth profile exists yet.

Image Image

Environment

  • OS: Windows
  • Shell: PowerShell
  • Databricks CLI: installed and reachable
  • Tool: ucode

Steps to Reproduce

  1. Start from a Windows machine with no existing Databricks CLI auth profile.
  2. Run ucode configure and complete the Databricks login flow.
  3. Select Claude during the provider/tool selection step.
  4. Close the terminal after configuration finishes.
  5. Open a new PowerShell terminal and run ucode claude.
  6. Claude Code starts, then fails with the apiKeyHelper error.

Expected Behavior

ucode claude should start Claude Code successfully on Windows and fetch the Databricks token without relying on POSIX shell syntax.

Actual Behavior

Claude Code fails before it can fully initialize because the generated apiKeyHelper command is interpreted incorrectly on Windows.

Likely Cause

The helper command returned for Claude appears to use POSIX shell logic such as:

if [ -n "${DATABRICKS_BEARER:-}" ]; then ...

That syntax is valid in sh/bash, but not in PowerShell or cmd.exe.

Recommendation

Update the Windows path so the helper command is generated as a PowerShell-compatible command. The helper should be written in a way that is safe for PowerShell and avoids POSIX shell syntax entirely. For example:

return (
  'powershell -NoProfile -NonInteractive -ExecutionPolicy Bypass -Command '
  f'"$ErrorActionPreference = \'Stop\'; '
  'if ($env:DATABRICKS_BEARER) { [Console]::Out.WriteLine($env:DATABRICKS_BEARER) } '
  f'else {{ [Console]::Out.WriteLine(({cli_command})) }}"'
)

This keeps the DATABRICKS_BEARER fallback, but makes the Windows branch explicit and avoids POSIX-only constructs such as [ -n ... ] and jq on Windows.

If possible, add a focused regression test that asserts the Windows helper contains a PowerShell command and not the POSIX shell branch.

Suggested Implementation Notes

  • Keep the existing POSIX helper for Unix-like systems.
  • Add a Windows-specific helper branch in the token command builder.
  • Preserve the DATABRICKS_BEARER fallback if it is already part of the design.

Acceptance Criteria

  • ucode claude works on Windows with a fresh Databricks setup.
  • The helper command used by Claude is valid in PowerShell.
  • Automated tests cover the Windows-specific branch.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions