Environment

Primer

Truthy Values

Some OCX options can be configured using environment variables instead of command line flags. For example, the --offline flag can be set by configuring the OCX_OFFLINE environment variable to a truthy value. Truthy values are case-insensitive and include:

• 1
• y
• yes
• on
• true

for enabling an option, and

• 0
• n
• no
• off
• false

for disabling an option.

Internal

Presentation flags do not propagate

The presentation flags --log-level, --format, and --color are CLI-only by design — they have no OCX_* counterpart and never propagate from a parent ocx into a subprocess (such as a generated entrypoint launcher). Carrying them through env would leak ocx's own logging, JSON output, or ANSI color choices into the launcher's child stream. Only resolution-affecting policy (binary path, offline, remote, config file, index) propagates.

Shell Activation Files

The ocx self setup command writes one thin shim file per supported shell family into $OCX_HOME. Each shim calls ocx self activate at shell start, which delegates runtime logic to the binary: PATH prepend, completion injection, and global toolchain env eval. Shim files are byte-identical across users — no install-time substitution occurs.

File	Shell	Mechanism	Wired by
$OCX_HOME/env.sh	bash, zsh, dash, ash, ksh	existence-guarded . "${OCX_HOME:-$HOME/.ocx}/env.sh" block-marker	ocx self setup writes block-marker to ~/.bash_profile, ~/.zprofile, or ~/.profile
$OCX_HOME/env.fish	fish	source "$OCX_HOME/env.fish" from conf.d	ocx self setup writes ~/.config/fish/conf.d/ocx.fish
$OCX_HOME/env.nu	nushell	Nushell autoload via vendor/autoload/	ocx self setup writes ~/.local/share/nushell/vendor/autoload/ocx.nu (auto-sourced)
$OCX_HOME/env.elv	elvish	existence-guarded eval (slurp < …/env.elv) block-marker	ocx self setup writes block-marker to ~/.config/elvish/rc.elv
$OCX_HOME/env.ps1	PowerShell	existence-guarded . …/env.ps1 block-marker in $PROFILE	ocx self setup writes block-marker to $PROFILE

Each shim resolves OCX_HOME at runtime using shell-native assign-if-unset syntax (e.g. : "${OCX_HOME:=$HOME/.ocx}"), so activation works in fresh shells where OCX_HOME has not been exported. The managed block in your profile resolves the same ${OCX_HOME:-$HOME/.ocx} fallback (the block sources env.sh, which is what exports OCX_HOME, so it cannot depend on it) and existence-guards the source, so a login shell with OCX_HOME unset never errors on a missing file.

These files are ocx-managed — customize your own RC

The env.* shims and the dedicated fish/nushell files (~/.config/fish/conf.d/ocx.fish, ~/.local/share/nushell/vendor/autoload/ocx.nu) are owned and regenerated by ocx self setup, and refreshed by ocx self update. They are rewritten to canonical content whenever they drift, without a --force prompt — the no-clobber-without---force guarantee applies only to the managed block inside your own shell profiles (~/.zshrc, ~/.bash_profile, $PROFILE, …). Put personal shell customization in those RC files, not in the ocx-managed files.

_OCX_ENV_LOADED

Set automatically to 1 by env.sh / env.fish / env.ps1 / env.nu / env.elv on first source to prevent double-application of OCX shell activation (PATH prepend, completions, env eval). Internal — do not set manually. Unset to force re-sourcing in the current shell session.

OCX_ACTIVATED

Set to 1 by the output of ocx self activate so re-sourcing the shell profile becomes a cheap no-op. The activation output emits both a guard line ([ -z "${OCX_ACTIVATED:-}" ] for POSIX shells, equivalent forms for fish / pwsh / elvish / nushell / cmd) wrapping the expensive ocx --global env --shell=NAME subprocess, and an unconditional marker line export OCX_ACTIVATED=1. The marker is also set on a fresh activation; subsequent re-sources see the marker and skip the eval. Mirrors mise's MISE_SHELL double-activation guard.

Internal — do not set manually. Unset (unset OCX_ACTIVATED / set -e OCX_ACTIVATED / Remove-Item Env:OCX_ACTIVATED) to force ocx self activate to re-run the global env eval in the current shell.

_OCX_APPLIED

REMOVED — this variable and the per-prompt shell hook that managed it (ocx shell hook) have been removed. Do not set or reference _OCX_APPLIED in shell profiles.

Global toolchain activation is now handled by $OCX_HOME/env.sh, sourced from the login profile via a block-marker idempotent line written by the installer. The file runs eval "$(ocx --global env --shell=sh)". Project toolchain activation uses ocx direnv.

OCX_AUTH_<REGISTRY>_TYPE

The authentication type for the registry.

Valid values are:

• basic
• token (or bearer)
• anonymous

OCX_AUTH_<REGISTRY>_USER

Configures the username for the registry when using basic authentication. The corresponding password should be configured using the OCX_AUTH_<REGISTRY>_TOKEN variable.

This value is ignored if the OCX_AUTH_<REGISTRY>_TYPE is not set to basic.

OCX_AUTH_<REGISTRY>_TOKEN

Configures the access token for the registry. For basic authentication, this value will be used as the password.

This value is ignored if the OCX_AUTH_<REGISTRY>_TYPE is not set to bearer or basic.

OCX_BINARY_PIN

Absolute path to an ocx executable. Set automatically by the running ocx on every subprocess it spawns so child ocx invocations — most importantly, the inner ocx launcher exec call inside a generated entrypoint launcher — pin to the same binary that installed the package, instead of falling back to whatever $PATH happens to resolve at the launcher site.

Unix

export OCX_BINARY_PIN=/usr/local/bin/ocx

PowerShell

$env:OCX_BINARY_PIN = "C:\Users\ci\.ocx\bin\ocx.exe"

When OCX_BINARY_PIN is unset, generated launchers fall back to $PATH-resolved ocx. Set it manually only when running a launcher outside an outer ocx invocation and you want to pin a specific binary (typical use: a wrapper that records arguments, or a release-candidate binary tested side-by-side with the installed one).

Windows .exe shim behavior. The native Windows .exe shim — the sole Windows launcher — honors this variable with Windows IF DEFINED semantics: if OCX_BINARY_PIN is defined in the environment, even as an empty string, the shim uses its value as the program path. Only when the variable is completely unset does the shim fall back to ocx via PATH. This differs from the Unix launcher's ${OCX_BINARY_PIN:-ocx} form, which treats an empty value as unset.

OCX_CONFIG

Path to an extra configuration file to load. The file layers on top of the discovered tier chain (system, user, $OCX_HOME/config.toml) at highest file-tier precedence — it does not replace them. Use it to refine ambient config without rewriting it, or combine with OCX_NO_CONFIG for a fully hermetic load.

Equivalent to the --config CLI flag, but injectable via environment — the intended use is CI and Docker setups where the env is controlled but the command line is not.

export OCX_CONFIG=/etc/ocx/ci.toml

If both OCX_CONFIG and --config are set, both load — --config sits at the highest file-tier precedence and wins on conflicting scalars. Missing files produce a clear error with the path.

Escape hatch: setting this to the empty string (OCX_CONFIG=) is treated as unset, not as an error. Useful when the variable is exported from a shell profile and you want to disable it for a single invocation without unsetting it.

OCX_DEFAULT_REGISTRY

The default registry to use when no registry is specified in a package reference on the command line. Overrides the [registry] default key in the configuration file. If neither is set, OCX uses ocx.sh.

OCX_GLOBAL

Selects the global toolchain tier — equivalent to the --global CLI flag, but injectable via environment for CI and container setups where the command line is not controlled.

When set to a truthy value, toolchain-tier commands (add, remove, lock, upgrade, pull, run, env) target $OCX_HOME/ocx.toml instead of a discovered project file. Equivalent to passing the root flag --global (before the subcommand): ocx --global add ripgrep:14.

export OCX_GLOBAL=1

This variable is resolution-affecting: it is forwarded to every subprocess ocx spawns via apply_ocx_config, so child invocations — generated launchers, nested ocx run calls — see the same tier selection.

No implicit fallback: the earlier implicit $OCX_HOME/ocx.toml discovery (home-tier fallback) has been removed. The global toolchain is only active when --global is explicitly passed or OCX_GLOBAL is set. Absent both, ocx does not discover any home-tier project file.

OCX_GLOBAL and OCX_PROJECT are mutually exclusive — setting both is a usage error (exit 64).

Strict isolation: the global toolchain never composes into project-tier resolution. ocx run and ocx exec are hermetic and never see global tools. Isolation is enforced by PATH precedence — project tools prepend before global tools when a project toolchain is active. See Environment Composition — Strict isolation for the full model.

WARNING

This variable is mostly intended for testing. It is recommended to specify the registry explicitly in the package reference.

OCX_HOME

The root directory for all OCX data — the object store, local index, and install symlinks. If not set, defaults to ~/.ocx.

export OCX_HOME="/opt/ocx"

OCX also discovers a configuration file at $OCX_HOME/config.toml — see the OCX home tier in the Configuration in-depth page.

OCX_INDEX

Override the path to the local index directory. By default, OCX reads the local index from $OCX_HOME/index/ (typically ~/.ocx/index/).

export OCX_INDEX="/path/to/bundled/index"

This variable is intended for environments where the index snapshot is bundled alongside a tool rather than stored in OCX_HOME — for example inside a GitHub Action, Bazel Rule, or DevContainer Feature.

The command line option --index takes precedence over this variable. This variable has no effect when --remote or OCX_REMOTE is set.

OCX_JOBS

Caps the number of root packages pulled in parallel — applies to every command that fans out through the package manager (install, pull, package pull, exec, env).

export OCX_JOBS=4

0 means "use all logical cores" (matches GNU parallel -j 0) and diverges from Cargo's --jobs 0, which errors. Negative or non-numeric values are ignored with a warning. Unset = unbounded (legacy default).

The command line option --jobs takes precedence over this variable.

OCX_INSECURE_REGISTRIES

A comma-separated list of registry hostnames (with optional port) that should be contacted over plain HTTP instead of HTTPS.

export OCX_INSECURE_REGISTRIES="localhost:5000,registry.local:8080"

WARNING

This variable disables TLS for the listed registries. Only use it for local development registries that do not support HTTPS.

OCX_MIRRORS

A JSON object that maps upstream registry hostnames to mirror endpoints. Each key is an upstream hostname; each value is the mirror url in the form scheme://host[/repo-key-prefix].

export OCX_MIRRORS='{"ghcr.io":"https://company.jfrog.io/ghcr-remote","docker.io":"https://company.jfrog.io/dockerhub-remote"}'

This variable is resolution-affecting: it is forwarded to every subprocess ocx spawns via apply_ocx_config, so child invocations — generated launchers, nested ocx run calls — see the same mirror map.

OCX_MIRRORS overrides the [mirrors."<host>"] config key on a per-host basis. A host present in OCX_MIRRORS replaces the config entry for that host; hosts absent from OCX_MIRRORS still come from [mirrors] in the config file.

Malformed values abort at startup

A malformed OCX_MIRRORS value is a hard startup error. OCX aborts with an error message naming the problem:

• The value is not valid JSON
• A per-host value is not a string URL
• A mirror url starts with http:// but the mirror host is not listed in OCX_INSECURE_REGISTRIES

OCX never silently continues with an empty mirror map when OCX_MIRRORS is set — falling back to no mirrors would silently route reads to the firewall-blocked origin, which is the exact failure replace semantics are designed to prevent.

For the full mirror semantics (replace behavior, auth, lockfile portability, interaction with --offline), see the [mirrors."<host>"] configuration reference.

OCX_LOG

The log level for OCX. You can set this variable to the same values as the --log-level command line option (e.g. warn, info, etc.). If --log-level is specified, it will take precedence over this environment variable. For more information on log levels, see the command line reference.

OCX_LOG_CONSOLE

Similar to OCX_LOG, but specifically for configuring the log level of messages emitted to the console. If OCX_LOG_CONSOLE is set, it will take precedence over OCX_LOG for console messages.

OCX_NO_CONFIG

When set to a truthy value, OCX skips the discovered configuration chain — no system, user, or $OCX_HOME/config.toml is loaded. Explicit paths supplied via --config or OCX_CONFIG still load, because they represent deliberate intent rather than ambient environment.

Use this for CI reproducibility: locked workflows should ignore any ambient config that might leak in from the runner image or a mounted home directory.

Combined with an explicit path, this is the canonical hermetic pattern:

OCX_NO_CONFIG=1 ocx --config /ci/ocx.toml install cmake:3.28

OCX_NO_CONFIG is available only as an environment variable. A --no-config CLI flag would duplicate surface without solving a new problem: the hermetic-CI use case is best expressed via env vars, which are how CI systems already inject policy. A flag would require callers to both export the env var and pass the flag in every per-command invocation — two sources of truth for the same intent.

OCX_NO_COMPLETIONS

When set to a truthy value, ocx self activate skips the shell-completion injection block. PATH prepend and global toolchain env eval still run.

Use this when you manage completions through a separate framework (e.g. oh-my-zsh or a Nix-generated completion store) and do not want OCX to overwrite them on every shell start.

export OCX_NO_COMPLETIONS=1

This variable has no effect on ocx shell completion, which always generates the completion script regardless.

OCX_NO_UPDATE_CHECK

When set to a truthy value, OCX will not check the remote registry for newer versions on CLI startup. By default, OCX prints a notice to stderr if a newer version is available in the remote registry.

The update check is also automatically suppressed when:

• CI is set to a truthy value
• OCX_OFFLINE is set to a truthy value (or --offline flag)
• stderr is not a terminal (e.g., piped or redirected)
• the command is version, about, or shell completion

To disable the check entirely (including suppressing the throttle state write), use this variable. To change the check frequency instead of disabling it, use OCX_UPDATE_CHECK_INTERVAL.

OCX_NO_PROJECT

When set to a truthy value, OCX skips project-tier discovery — the CWD walk for ocx.toml is pruned and OCX_PROJECT is ignored. Explicit paths supplied via --project still load, because they represent deliberate intent rather than ambient environment.

Use this for CI reproducibility when you want to run ocx inside a repository without the project-tier toolchain influencing the invocation.

Combined with an explicit path, this mirrors the hermetic pattern used for OCX_NO_CONFIG:

OCX_NO_PROJECT=1 ocx --project /ci/ocx.toml exec -- cmake --version

OCX_NO_PROJECT is available only as an environment variable. A --no-project CLI flag would duplicate surface without solving a new problem — the hermetic-CI use case is best expressed via env vars, matching the OCX_NO_CONFIG pattern.

OCX_HOME role in setup

When you run ocx self setup, it uses OCX_HOME (default ~/.ocx) as the root for two things: the location it writes the five env shim files (env.sh, env.fish, env.ps1, env.nu, env.elv), and the directory that the shims themselves resolve at runtime via shell-native assign-if-unset syntax (e.g. : "${OCX_HOME:=$HOME/.ocx}"). Setting OCX_HOME to a non-default path before running ocx self setup puts all shims and the object store under that path consistently. See OCX_HOME for the full data-directory reference.

OCX_NO_MODIFY_PATH

When set to a truthy value, ocx self setup writes the env shim files to $OCX_HOME but skips modifying any shell profile. Use this in CI environments or when you manage your PATH manually.

The equivalent CLI flag is --no-modify-path on ocx self setup.

Truthy values only — not "any non-empty"

OCX_NO_MODIFY_PATH follows the same truthy/falsy rules as OCX_OFFLINE and OCX_REMOTE. Only the values in the truthy list (1, y, yes, on, true, case-insensitive) enable the flag. An unrecognized non-empty value (e.g. OCX_NO_MODIFY_PATH=skip) logs a warning and is treated as the default (false — profiles are modified). An empty string is also treated as false.

The opt-out is not remembered between runs. A user who ran ocx self setup --no-modify-path once, then runs ocx self setup again without the flag, will have profiles modified. To make the opt-out persistent, either:

• Export OCX_NO_MODIFY_PATH=1 in your environment before every ocx self setup invocation, or
• Pass --no-modify-path each time.

A $OCX_HOME/state/no-modify-path sentinel file that persists the preference automatically is planned for a future release.

Profile-indirection limitation. Shell activation through $OCX_HOME/env.* only takes effect inside interactive PowerShell and POSIX shell sessions that source the login profile. It does not register OCX_HOME/bin with Windows HKCU\Environment — cmd.exe sessions and GUI applications launched from the desktop do not inherit the PATH update until you open a new PowerShell or bash session and source the profile. If you need OCX tools visible to cmd.exe or GUI apps, set PATH via System Properties or a Group Policy, or use ocx self setup alongside a separate HKCU\Environment update.

OCX_NO_CODESIGN

When set to a truthy value, OCX will skip ad-hoc code signing of macOS binaries after installation. By default, OCX automatically applies ad-hoc code signatures to extracted Mach-O binaries on macOS, which is required for execution on Apple Silicon. See the FAQ for details on why this is necessary and how it works.

This variable has no effect on non-macOS systems.

OCX_QUIET

When set to a truthy value, OCX suppresses the structured stdout report that every command emits — tables in plain mode, the JSON document in --format json mode. Errors, warnings, and progress on stderr are unaffected.

The command line option --quiet takes precedence over this variable.

OCX_OFFLINE

When set to a truthy value, OCX disables all network access. Tag→digest resolution must be satisfied by the local index or by a digest-pinned identifier; unpinned tags missing from the local index error immediately. Useful for hermetic CI runs and air-gapped environments. The command line option --offline takes precedence over this variable.

Combined with OCX_REMOTE, enables pinned-only mode: no source contact, no local writes, and any tag-addressed resolution that cannot be satisfied locally errors instead of falling back.

OCX_PROJECT

Path to a project-tier ocx.toml to load. Bypasses the CWD walk — the named file is used directly. Not part of the ambient configuration chain: the project tier is a separate API surface from the ambient config tier loaded via OCX_CONFIG.

Equivalent to the --project CLI flag, but injectable via environment — the intended use is CI and Docker setups where the env is controlled but the command line is not.

export OCX_PROJECT=/workspace/ocx.toml

Precedence: --project > OCX_PROJECT > CWD walk. OCX_NO_PROJECT=1 prunes both the CWD walk and this env var, but does not block an explicit --project flag. Missing files produce a clear error with the path.

Escape hatch: setting this to the empty string (OCX_PROJECT=) is treated as unset, not as an error. Useful when the variable is exported from a shell profile and you want to disable it for a single invocation without unsetting it.

Symlink policy: explicit paths (this variable and --project) follow symlinks. The CWD walk rejects symlinked ocx.toml candidates — use --project or OCX_PROJECT to opt in.

OCX_REMOTE

When set to a truthy value, routes mutable lookups (tag list, catalog, tag→manifest resolution) to the remote registry instead of the local index. Pure-query commands (ocx index list, ocx index catalog, ocx package info) do not persist results to the local index — to refresh the snapshot, run ocx index update explicitly. Digest-addressed reads still consult the local index first (immutable content is safe to cache).

Equivalent to passing the --remote flag on every invocation. See the user guide for the routing model and the pinned-only mode (combined with OCX_OFFLINE).

OCX_FROZEN

When set to a truthy value, freezes tag→digest resolution to the local index. A tag already in the local index resolves from cache; a digest-pinned identifier (repo@sha256:…, or a tag pinned by ocx.lock) still fetches its content over the network. An unpinned tag missing from the local index errors with exit code 81 instead of being fetched and recorded — the guarantee that no unknown version is installed.

Unlike OCX_OFFLINE, this is not a network ban: known and digest-pinned content is still fetched. It only refuses to discover a new tag→digest mapping. Run ocx index update to populate the index first.

Equivalent to passing the --frozen flag on every invocation; the flag takes precedence. Mutually exclusive with OCX_REMOTE (combining the two is a usage error, exit 64); combining with OCX_OFFLINE is accepted, with offline taking effect.

OCX_UPDATE_CHECK_INTERVAL

Override the minimum interval between automatic update-check registry probes. The check runs once per shell invocation after the interval elapses; it is a background notification only and does not block the command.

Value	Behaviour
Unset	Default 24-hour interval
0	Always check on every eligible invocation (bypass throttle)
Positive integer	Custom interval in seconds

export OCX_UPDATE_CHECK_INTERVAL=3600   # check at most once per hour
export OCX_UPDATE_CHECK_INTERVAL=0      # always check (development use)

The state file that tracks the last probe is at $OCX_HOME/state/update-check/ocx_sh_ocx_cli. Its mtime is the data — the file is zero bytes.

The automatic update check is also suppressed when stderr is not a terminal (typical CI runners, pipelines, and redirected output) and when CI is set. Setting OCX_UPDATE_CHECK_INTERVAL does not override these suppressions — the notification is intentionally invisible in non-interactive contexts.

To disable the check entirely rather than adjusting its frequency, use OCX_NO_UPDATE_CHECK. The explicit ocx self update and ocx self update --check commands always bypass this interval — they are explicit user intent.

Script env access (ocx package test --script)

ocx.env(name) in a Starlark test script reads one variable from the composed package env — the same env surface that ocx exec exposes. It does not read the host process env.

No new OCX_* variable was introduced by the --script feature. The resolution-affecting variables listed above (OCX_BINARY_PIN, OCX_HOME, OCX_CONFIG, OCX_PROJECT, OCX_INDEX, and others) remain inaccessible to script ocx.env() calls and cannot be overridden via the ocx.run(env=...) overlay kwarg — those keys are reserved and any attempt to set them results in a Failed outcome.

ocx-mirror

The ocx-mirror tool lives in its own repository. Its environment variables are documented in the ocx-mirror environment reference.

External

CI

When set to a truthy value, OCX suppresses the update check on startup. Most CI systems (GitHub Actions, GitLab CI, Travis, etc.) set this automatically.

CI Integration Variables

ocx env --ci and ocx package env --ci read a small set of runner-provided variables to locate the CI system's persistence channel. These variables are read by OCX from the runner environment — they are not OCX configuration and carry no OCX_ prefix.

Variable	Provider	Purpose
GITHUB_ACTIONS	GitHub Actions	Provider auto-detection
GITHUB_ENV	GitHub Actions	Sink for non-PATH entries
GITHUB_PATH	GitHub Actions	Sink for PATH-type entries
GITLAB_CI	GitLab CI/CD	Provider auto-detection

These variables are not forwarded to child ocx processes

OCX's config-forwarding set propagates only OCX_* resolution-affecting variables to subprocesses (launchers, nested ocx run). The runner variables above are not in that set — a child ocx invocation will not inherit them. This is intentional: the CI sink files are runner-managed paths and must not propagate through forked environments.

GITHUB_ACTIONS

Set to true by GitHub Actions runners. OCX reads this variable to auto-detect the CI provider when --ci is passed without an explicit provider value, and to suppress the update check on startup.

GITHUB_PATH

Set by GitHub Actions to a file path. Workflow steps append one directory per line to this file; each appended directory is prepended to PATH for all later steps. ocx env --ci=github and ocx package env --ci=github write only the literal PATH variable here — one directory per line, in prepend order — so OCX-installed tool directories land leftmost (highest priority) in PATH for every subsequent step, regardless of when the step runs.

All other path-type variables (such as LD_LIBRARY_PATH, MANPATH, PKG_CONFIG_PATH) are written to GITHUB_ENV as KEY=value, not to this file.

GITHUB_ENV

Set by GitHub Actions to a file path. Workflow steps append environment variables to this file using KEY=VALUE syntax (or heredoc delimiters for multiline values); the runner exports each entry to all later steps. ocx env --ci=github and ocx package env --ci=github write all non-PATH entries here: constant-type variables as KEY=VALUE, and path-type variables other than PATH (such as LD_LIBRARY_PATH) as KEY=<prepended-value> with OCX-provided directories prepended to the existing value.

GITLAB_CI

Set to true by GitLab CI/CD runners. OCX reads this variable to auto-detect the CI provider when --ci is passed without an explicit provider value.

DOCKER_CONFIG

The location of the Docker configuration directory. Read by the Docker credential helper that ocx delegates to when resolving registry credentials from ~/.docker/config.json.

OCX_AUTH_* environment variables (see above) take priority over any credential stored in the Docker configuration directory at read time. The resolution order for a given registry is: OCX_AUTH_TOKEN / OCX_AUTH_USER + OCX_AUTH_PASSWORD (highest) → credHelpers[registry] → credsStore → auths[registry] (lowest).

XDG_CONFIG_HOME

User-level configuration base directory, defined by the XDG Base Directory Specification. On Linux, OCX uses it to locate the user-tier configuration file: the user tier is $XDG_CONFIG_HOME/ocx/config.toml, falling back to ~/.config/ocx/config.toml when the variable is unset.

On macOS, XDG_CONFIG_HOME is not consulted. The user-tier path is ~/Library/Application Support/ocx/config.toml, following Apple's directory conventions. Use the OCX home tier ($OCX_HOME/config.toml, default ~/.ocx/config.toml) if you want a platform-neutral user config path.

OCX does not write anything to these directories — the config loader is read-only. This follows the convention for CLI tools that need user-level configuration separate from data (~/.ocx/).

NO_COLOR

When set to any non-empty value, disables ANSI color output. This is a cross-tool convention for respecting user color preferences. The --color flag takes precedence.

CLICOLOR

When set to 0, disables color output. Part of the CLICOLOR convention.

CLICOLOR_FORCE

When set to a non-zero value, forces color output even when stdout is not a terminal. Overrides CLICOLOR but is itself overridden by NO_COLOR.

RUST_LOG

A fallback for configuring the log level of OCX and its dependencies. If OCX_LOG is not set, OCX will respect the log level configured via RUST_LOG. The format for this variable is the same as for OCX_LOG.