Diagnose provider detection, authentication, model discovery, executable paths, versions, and account-specific behavior on Windows.

For a CLI agent, verify the provider outside Tejus first. Tejus can discover and run a provider CLI, but it cannot repair a missing executable, an expired provider session, an unavailable model, or an account restriction inside that provider.

The built-in Tejus agent has no CLI. If it is unavailable, check your Tejus account in Settings → Account and see Tejus Cloud.

Provider is not detected

Tejus reports this as, for example, “Codex CLI (codex) is not installed or not on PATH.”

Open a new PowerShell window

Do not reuse a window that was open before the provider was installed or PATH changed.

Run the provider executable

Use the command documented in the relevant provider guide. For example:

claude --version
codex --version
opencode --version
cursor-agent --version

Check the resolved path

Get-Command <provider-command>
where.exe <provider-command>

Confirm the result is the installation you want Tejus to use. npm installs usually resolve to a .cmd file under %APPDATA%\npm; Tejus runs these through cmd.exe automatically.

Check Tejus provider settings

Open Settings → Agent providers. Under Provider activity, make sure the provider is enabled (a disabled provider reports “Provider is disabled in Tejus settings.”). Under Provider tools, expand the provider and check the binary path in its Runtime section. Clear an obsolete path rather than keeping it “just in case”.

Restart Tejus and refresh

Tejus reads your saved user and system environment variables, including PATH, from Windows when it starts. Fully quit and reopen Tejus after installing a CLI or changing PATH, then click Refresh status in Settings → Agent providers.

Projects on a WSL path

When a project is opened from a path such as \\wsl.localhost\<distro>\... or \\wsl$\<distro>\..., Tejus launches provider CLIs inside that WSL distribution through wsl.exe. Install and sign in to the CLI inside the distribution, not only on Windows.

Provider is detected but not authenticated

Use Sign in for the account under Settings → Agent providers → Provider tools. Tejus opens the provider's own login command in a terminal; follow its prompts, then click Check authentication. Opening the browser does not by itself confirm sign-in.

You can also run the provider's status or login flow in a normal terminal. Examples:

claude auth status
codex login status
cursor-agent status

Other providers sign in through an interactive command, a device flow, configured model-provider credentials, or an environment variable.

Check:

The same executable is used inside and outside Tejus
The signed-in account is the intended account
Required environment variables reach Tejus: either set them as Windows user variables and restart Tejus, or add them to the provider's Environment section in Provider tools
A cached account session is not taking precedence over an API key, or the reverse
Enterprise or cloud-provider credentials are available in the same environment

Never paste an API key into a task to “test” authentication.

Authentication state is unknown or stale

Some providers do not expose a login status. OpenCode, Pi, and Oh My Pi are always shown with unknown authentication, and Grok, Droid, and Devin are shown as authenticated only when Tejus finds an API key or stored login. Run a small test task to confirm.

Provider health checks are also time-limited (a few seconds for most CLIs, longer for Claude Code and OpenCode). A timeout is not proof that authentication failed.

Test the provider directly.
Wait for the provider's own command to complete.
Click Refresh status in Settings → Agent providers.
Restart Tejus if the executable or credentials changed.
Record the exact provider command and output when the discrepancy remains.

Models are missing

Model discovery can depend on:

Provider CLI version
Account or subscription
Region
Organization policy
Global and project-level configuration
Custom model-provider credentials
Working directory
Provider service availability

Compare the model list from the exact provider executable in the same repository. Do not assume that a model visible in a web app, editor, or different CLI installation must appear in Tejus.

The wrong executable is used

This is common when several installation methods coexist.

Examples:

An npm install and a native installer install of the same CLI
npm, pnpm, and Bun global installs side by side
Stable and development builds
A generic command name shadowing the intended provider
A custom binary path left over from an older machine

Record:

Get-Command <provider-command> -All
<provider-command> --version

Then point Tejus at the intended executable or clear the custom path to restore automatic discovery.

Provider is outdated

With Automatic CLI update checks on (the default), Settings → Agent providers → Updates lists installed CLIs that have a newer version. Tejus detects how a CLI was installed (npm, pnpm, Bun, or the provider's own installer) and offers Update when it can run a safe update command for that installation; otherwise the row shows Manual update. CLIs that manage their own releases offer the update inside their Provider tools row, because Tejus cannot tell whether a newer version exists.

When you update yourself, use the provider's documented update path, then:

Verify the new version in a new PowerShell window.
Restart Tejus.
Refresh provider status.
Start a new task when protocol negotiation or model options changed.

Do not run a package-manager update against an installation owned by a different package manager.

Provider works directly but fails in Tejus

Compare these variables:

Variable	Why it matters
Executable path	You may be testing a different installation
Working directory	Project configuration can change provider behavior
Account	Model access and limits differ
Model and options	A valid model can still reject an unsupported option
Permission mode	Tool and approval behavior changes
Environment variables	Tejus may have started with a different environment
Provider version	ACP, resume, compaction, and event behavior can change
Project instructions	Repository-local rules can alter the session

Create a small new task using the simplest model and default options. If that works, add one custom variable at a time.

Provider process exits immediately

Run the provider directly from the task's working directory. Look for:

Invalid configuration
Missing credentials
Unsupported flags or model options
A broken extension, plugin, hook, or MCP server
Permission errors
A provider-side outage
A version too old for the integration Tejus expects

Disable optional provider extensions only when you can restore them. Preserve the failing configuration and exact output for the report. Provider logs are written under %USERPROFILE%\.tejus\userdata\logs\provider\.

Provider-specific guides

Use the dedicated guide for exact commands and behavior:

Provider troubleshooting checklist

The exact executable runs in a new PowerShell window
The resolved path and version were recorded
Authentication succeeds outside Tejus
The intended model works directly
Custom binary paths were checked
Tejus was restarted after environment changes
Optional provider configuration was isolated one variable at a time
Secrets were removed from every shared log or screenshot