Issue: Codex Login Check Fails on Linux (Hardcoded Binary Path & Command Typo)

[obriedan]

Disclaimer: GeminiCLI wrote the below. The issue is valid, however I am unsure if its assessment of the root cause is, or if its suggested fix is sufficient. -- love the app btw, using it daily.

Description
The application fails to recognize valid Codex CLI login status on Linux
systems. Even after a successful codex login via the terminal, the UI
continues to report that the user is not logged in and prompts an incorrect
login command.

Root Causes
There are two primary issues in the current implementation of the YOKE adapter
layer:

1. Hardcoded Binary Path: In lib/yoke/index.js, the checkCodex and
   checkInstalled functions use a hardcoded path specifically for the Darwin
   (macOS) ARM64 package (@openai/codex-darwin-arm64). This causes the auth
   check to fail on Linux and other architectures because the binary is never
   found.
2. Incorrect Login Command: In lib/sdk-bridge.js, the loginCommand provided
   to the UI is hardcoded as codex --login. The correct command for the Codex
   CLI is codex login.

Technical Details

1. lib/yoke/index.js
   The current check is hardcoded to a Mac-specific path:

1 var codexBin = path.join(__dirname,
"../../node_modules/@openai/codex-darwin-arm64/vendor/aarch64-apple-darwin/
codex/codex");
This should instead use the dynamic findCodexPath() helper already defined in
lib/yoke/codex-app-server.js or fallback to checking the system PATH.

2. lib/sdk-bridge.js
   The UI prompt uses an invalid flag:

1 loginCommand: session.vendor === "codex" ? "codex --login" : session.vendor
+ " login",

Steps to Reproduce

1. Install Codex on a Linux environment.
2. Run codex login and authenticate successfully.
3. Start a new session in the application and select Codex as the vendor.
4. The application returns an "Auth Required" error even though the CLI is
   authenticated.
5. The UI suggests running codex --login, which is an invalid command.

Suggested Fix

1. Refactor Binary Discovery: Move findCodexPath() to a shared utility or
   export it from codex-app-server.js. Update lib/yoke/index.js to use this
   helper.
2. Add System Path Fallback: Update checkCodex to also attempt running codex
   login status directly if the node_modules binary isn't found, allowing it
   to work with globally installed versions of the CLI.
3. Fix Command Typo: Update the loginCommand string in lib/sdk-bridge.js to
   codex login.

[chadbyte]

Hey @obriedan, both halves are fixed and shipped in v2.32.1-beta.2:

• fix(ui,sdk-bridge): 'codex --login' -> 'codex login' in loginCommand prompts #329 (+ follow-up): login prompt now says codex login --device-auth instead of the invalid codex --login
• fix(yoke): use findCodexPath() instead of hardcoded darwin-arm64 path #330: binary path resolves per-platform via findCodexPath() instead of the hardcoded Darwin ARM64 path

Could you try npx clay-server@main and confirm it works on your Linux setup?

Thanks for the writeup.

btw, curious: when do you usually reach for Clay, and is there stuff you end up doing in other tools instead?

[obriedan]

I've updated to 2.33.0. The login prompt still appears, though the type for the CLI login prompt is now correct.

I am not a developer, so I've asked GeminiCLI to clone the updated version locally and locate any issues based on how Codex is configured on my system with the current code and any logs from Clay on the device. This is its report, verbatim.

I have identified the root cause of the issue.

1. Incorrect Linux Path Resolution: In lib/yoke/codex-app-server.js, the app
   expects Linux binaries to be in a directory named x86_64-unknown-linux-gnu
   (or aarch64-...). However, the official @openai/codex-linux-* packages use
   x86_64-unknown-linux-musl (and aarch64-unknown-linux-musl) for their
   internal vendor folder structure. This mismatch causes the app to look for
   the binary in a folder that doesn't exist.
2. Missing PATH Fallback: While other parts of the app (like
   lib/sdk-bridge.js) correctly fall back to checking the system PATH if the
   bundled binary isn't found, the core authentication check in
   lib/yoke/index.js only checks the bundled path. Since you have codex in
   your PATH, the app should be able to find it, but the checkAuth logic is
   being too restrictive.

I've verified this on your system:

• The app looked for: .../vendor/x86_64-unknown-linux-gnu/codex/codex
  (Doesn't exist)
• The binary is actually at: .../vendor/x86_64-unknown-linux-musl/codex/codex
  (Exists and works)

Info for the Developer:

File: lib/yoke/codex-app-server.js
The getTargetTriple() function and PLATFORM_PACKAGE_BY_TARGET mapping should
use musl instead of gnu for Linux to match the @openai/codex package
structure:

1 // Current
2 "aarch64-unknown-linux-gnu": "@openai/codex-linux-arm64",
3 "x86_64-unknown-linux-gnu": "@openai/codex-linux-x64",
4
5 // Should be
6 "aarch64-unknown-linux-musl": "@openai/codex-linux-arm64",
7 "x86_64-unknown-linux-musl": "@openai/codex-linux-x64",

File: lib/yoke/index.js
The checkCodex() and checkInstalled() functions should fall back to checking
the system PATH if findCodexPath() fails or the resulting path does not exist,
similar to the logic in lib/sdk-bridge.js.

---

Primary use case for Clay is as a personal productivity assistant. Claude manages the obsidian vault that lives on my homelab. I needed both mobile interface and something I could use through a Cloudflare tunnel. Been using it almost daily since the start of March. Only on the Claude Pro plan, so I haven't leveraged Mates yet due to token constraints. I reach for GeminiCLI for homelab sysadmin related tasks, some research, and as a headless subagent Claude uses for token heavy work on the vault. It would be great if Clay could support the GeminiCLI as well.

After noticing Codex pop up on the Clay changelog, I was hoping to use it to try out building some Mates and see how they could work to improve the productivty system.

[obriedan]

I asked Gemini if it could test its findings in the currently running Clay process. The result was successful. Summary from Gemini.

Diagnosis Confirmed:
The findCodexPath logic in lib/yoke/codex-app-server.js was targeting x86_64-unknown-linux-gnu,
but the @openai/codex-linux-x64 package (v0.121.0) stores the binary under
vendor/x86_64-unknown-linux-musl/.

Verification Hack:
Modified lib/yoke/codex-app-server.js in the npx cache:

1 // From:
2 "x86_64-unknown-linux-gnu": "@openai/codex-linux-x64",
3 // To:
4 "x86_64-unknown-linux-musl": "@openai/codex-linux-x64",
(Same for aarch64 and the getTargetTriple() function).

Result:
After process restart, Clay successfully spawned the Codex app-server. checkAuth now returns
codex=true. Verified tool execution (Bash/Edit) works as expected.

Recommendation:

1. Update lib/yoke/codex-app-server.js to use musl for Linux triples.
2. In lib/yoke/index.js, update checkCodex() and checkInstalled() to fall back to which codex
   (system PATH) if the bundled binary resolution fails. Currently, they only check the guessed
   path, making the app fragile to package structure changes