ci-redact does not respect FNOX_PROFILE

[Kovah]

I just switched a project to a setup with Vault + fnox. Locally, I use the 1Password provider to access the Vault token. In a Github CI pipeline, the Vault token should be supplied by the hashicorp/vault-action. This means, that I have no access to 1Password in the CLI.

I thought I solved this by moving the 1Password provider into a development profile, while all secrets used for the production deployment live in their own profile.

[providers]
vault = { type = "vault", path = "my-projects/project/secrets" }

[profiles.production.secrets]
APP_KEY = { provider = "vault", value = "production/APP_KEY" }

[profiles.development.providers]
onepass = { type = "1password" }
vault = { type = "vault", token = { secret = "VAULT_TOKEN" }, path = "my-projects/project/secrets" }

[profiles.development.secrets]
VAULT_TOKEN = { provider = "onepass", value = "op://Projects/Vault/token" }
APP_KEY = { provider = "vault", value = "production/APP_KEY" }

The ci-redact command works as expected with --profile production:

Run fnox --profile production -v ci-redact
2026-07-23T17:23:56.359990Z DEBUG fnox: Using config file: fnox.toml
2026-07-23T17:23:56.360971Z DEBUG fnox::commands::ci_redact: Redacting secrets from profile 'production'

However, when I set FNOX_PROFILE=production as an environment variable, the command fails because it wants to access secrets from the development profile.

Run fnox -v ci-redact
2026-07-23T19:44:33.404272Z DEBUG fnox: Using config file: fnox.toml
2026-07-23T19:44:33.405413Z DEBUG fnox::commands::ci_redact: Redacting secrets from profile 'development'

Is this intended behavior? From my impression and reading the source code, I though that ci-redact would respect the profile setting instead of fetching all secrets.

[jdx]

Thanks for the detailed report! I dug into this and ci-redact does respect FNOX_PROFILE — I wasn't able to reproduce the bug, but I think I can explain what you're seeing.

ci-redact resolves the profile exactly like every other command, via Config::get_profile:

profile_flag                                   // -P/--profile
    .or_else(|| (*env::FNOX_PROFILE).clone())   // FNOX_PROFILE env var
    .unwrap_or_else(|| "default".to_string())   // fallback

The Redacting secrets from profile '…' debug line prints exactly this resolved value, before any provider lookup — so the string in the log is what fnox read from the flag/env.

I built fnox 1.29.0 from main, faked a GitHub Actions environment, and used your config. Results:

Invocation	Resolved profile
fnox --profile production … ci-redact	production ✅
FNOX_PROFILE=production fnox … ci-redact	production ✅ (tries vault, never 1Password)
FNOX_PROFILE=development fnox … ci-redact	development → tries 1Password (your symptom)
FNOX_PROFILE= or a stray newline	falls back to default + a warning

So the env var is honored in every case. The key detail: an empty/invalid FNOX_PROFILE falls back to default, not development. The only way to get Redacting secrets from profile 'development' is for FNOX_PROFILE to literally be development when fnox runs — which means something set it to development in that step's environment rather than production.

Common GitHub Actions reasons for this:

• A job- or workflow-level env: FNOX_PROFILE: development (e.g. matching your local default) that the CI step never actually overrode.
• Setting it with export FNOX_PROFILE=production in a previous step — environment doesn't carry across steps. You need:

  echo "FNOX_PROFILE=production" >> "$GITHUB_ENV"

• A mise / direnv / .env activation seeding FNOX_PROFILE=development.

Could you share:

1. The relevant snippet of your workflow YAML (where/how FNOX_PROFILE is set relative to the fnox step), and
2. The output of fnox doctor in that same step — it prints the FNOX_PROFILE it sees.

That'll confirm whether the env var is reaching the step as production. My strong suspicion is it's arriving as development, but if fnox doctor shows production while ci-redact shows development, that would be a genuine bug and I'll dig further.

This comment was generated by Claude Code.

[Kovah]

Thanks for having a look at this.
This is an example workflow file that caused the issues, with irrelevant parts removed:

jobs:
  test:
    name: test
    runs-on: ubuntu-latest
    env:
      FNOX_NON_INTERACTIVE: true
      FNOX_PROFILE: production
      FNOX_DAEMON: 'off'
    steps:
      - uses: actions/checkout@v7

      - name: Install mise + fnox
        run: |
          npm install -g mise
          mise use -g fnox vault
          echo "$HOME/.local/share/mise/shims" >> "$GITHUB_PATH"

      - name: Fetch secrets from Vault
        uses: hashicorp/vault-action@v3
        with:
          url: ${{ vars.VAULT_ADDR }}
          method: jwt
          path: jwt
          role: my-project
          exportEnv: false
          exportToken: true

      - name: Fetch secrets via fnox
        run: |
          echo "FNOX_PROFILE = $FNOX_PROFILE"
          echo "FNOX_PROFILE via env = ${{ env.FNOX_PROFILE }}"
          fnox --version
          fnox exec -- env | grep FNOX_PROFILE
          fnox -v ci-redact
          fnox -v export --format env >> "$GITHUB_ENV"

and this is the related output:

FNOX_PROFILE = production
FNOX_PROFILE via env = production
fnox 1.31.0
2026-07-24T06:34:59.393319Z ERROR fnox_core::secret_resolver: Error resolving secret 'VAULT_TOKEN': 1Password: CLI tool 'op' not found
Error: fnox::provider::cli_not_found (https://fnox.jdx.dev/providers/1password)
  × 1Password: CLI tool 'op' not found
  help: Install the op CLI tool:
          brew install 1password-cli

For me the FNOX_PROFILE handling looks correct. Not sure where the fnox command right after the correct FNOX_PROFILE diverts. I guess it's a regression in the latest version, as you said you tested this with 1.29, and not the latest 1.31.

[jdx]

Thanks — the new output helps narrow this down. One important detail is that this run never reaches ci-redact: it fails in the preceding command:

fnox exec -- env | grep FNOX_PROFILE

fnox exec resolves all selected secrets before it starts env, so the 1Password error is coming from exec, not ci-redact.

I reproduced the posted configuration with the official fnox v1.31.0 binary. With FNOX_PROFILE=production, both:

fnox -v exec -- env
fnox -v ci-redact

resolve the production profile, use the top-level Vault provider, and never attempt to resolve VAULT_TOKEN through 1Password. I also reviewed the v1.31.0 multi-profile change and don't see a path that would turn production into development.

Could you replace the failing diagnostic with these and share the complete output?

env | sort | grep '^FNOX_'
fnox doctor
fnox config-files
fnox -P production -v exec -- env
fnox -P production -v ci-redact

In particular, fnox doctor will show the profile fnox itself sees without first resolving secrets, and fnox config-files should reveal whether a global, parent, or profile-specific config omitted from the example is being merged. If the explicitly profiled exec still tries 1Password, the complete set of config files reported there should make the remaining issue reproducible.

This comment was generated by OpenAI Codex.

[Kovah]

Hm, not sure which part exactly caused this behavior. I am sure the setup is actually broken for me, but can't figure out the cause. Switching all commands to --profile works, so it's not a dealbreaker.