[dheerenmohta]

airflow connections list and airflow variables list only enumerate metadata-database rows, but connections/variables can also be defined via AIRFLOW_CONN_*/AIRFLOW_VAR_* environment variables or a configured secrets backend — sources that take precedence over the database at resolution time and can silently override a DB row with the same ID, yet never appeared in the list output.

Adds get_hidden_entries_warning() (airflow-core/src/airflow/cli/utils.py), used by both connections_list() and variables_list(), printing a warning naming which source(s) — env-var prefix and/or secrets backend — may hold additional entries not visible in the listing. The warning goes to stderr via AirflowConsole(stderr=True), so --output json/yaml piping is unaffected.

Scoped to the CLI only in this PR — the Web UI listing mentioned in the issue would need new fields on the OpenAPI-generated REST API response models plus a TypeScript client regen, which is a materially larger, separate change. Happy to follow up with that as a second PR if useful.

related: #10867

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Sonnet 5)

Generated-by: Claude Code (Sonnet 5) following the guidelines

[SameerMesiah97]

Looks fine. Just some minor comments to address.

[ColtenOuO]

I think the overall direction looks good, but I have a concern about the maintainability of this detection logic.

Airflow 3 supports a worker-specific secrets backend through [workers] secrets_backend, which the Task SDK prioritizes during secret resolution. The current implementation only checks [secrets] backend, so it misses that case.

More generally, if future Airflow versions introduce secrets backend settings for other components or contexts, the CLI logic would also need to be updated to recognize each new configuration.

Otherwise, the same problem this PR is trying to solve could reappear.

Could we avoid duplicating knowledge of the available secret sources in the CLI?

Alternatively, the CLI could simply display a generic note that the command only lists entries stored in the metadata database and that the result may not represent every source used during runtime, without trying to identify the specific sources.

[ColtenOuO]

Thanks! LGTM.

[potiuk]

Approved this earlier; adding three follow-up observations from a closer read. None of them gates the merge — but the first is a factually wrong comment, and the third is the maintainability concern from the earlier review, which I don't think is fully closed.

• airflow-core/tests/unit/cli/commands/test_connection_command.py:152 — the comment explaining why AIRFLOW_CONN_* is cleared names the wrong mechanism.
• test_connection_command.py:174 / test_variable_command.py:346 — both does_not_warn_by_default tests assert stderr == "" without pinning [secrets] backend / [workers] secrets_backend.
• airflow-core/src/airflow/cli/utils.py:123 — the section/key pairs duplicate what _get_custom_secret_backend() already owns; the drift risk raised earlier in this PR is still open.

Details inline.

For the record, things I checked that are fine: moving from airflow.configuration import conf to module level is not an eager-config-load regression (airflow/__main__.py:36 already imports airflow.configuration, and cli_parser.py:49 pulls in providers_manager), so that change was the right response to the earlier review; AirflowConsole(stderr=True) forwards correctly to rich's Console through **kwargs; both config keys exist with "" defaults, so the any() check behaves; and no newsfragment is needed here per AGENTS.md.

One judgment call I'll leave to the thread rather than file as a finding: with a secrets backend configured — which is the norm in production — this warning now fires on every connections list / variables list invocation, with no way to suppress it. Routing it to stderr keeps pipes clean, so it is probably the right trade, but it is a permanent banner for a lot of users.

---

This review was drafted by an AI-assisted tool and confirmed by an Airflow maintainer. The findings above are observations, not blockers; an Airflow maintainer — a real person — will take the next look at the PR. If you think a finding is mis-applied, please reply on the PR and a maintainer will weigh in.

More on how Airflow handles maintainer review: contributing-docs/05_pull_requests.rst.

---

Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting

[dheerenmohta]

Thanks for the detailed follow-up — addressed all three in 8a5420e:

• test_connection_command.py:153 — corrected the comment. It now names the module-level clear_connections fixture generically rather than pointing at the wrong clear_db_connections/create_default_connections call chain.
• test_connection_command.py:174 / test_variable_command.py:346 — both now pin [secrets] backend and [workers] secrets_backend to "" via conf_vars, matching the pattern already used in TestGetHiddenEntriesWarning. Applied the same fix to test_utils.py::test_returns_none_when_nothing_is_hidden / test_warns_about_env_var_defined_entries, which had the same gap one level down.
• cli/utils.py:123 — lifted the (section, key) pairs into a new SECRETS_BACKEND_CONFIG_KEYS constant in shared/configuration/src/airflow_shared/configuration/parser.py, and pointed _get_custom_secret_backend() at the same constant. Both now read from one place, so a future third source only needs to be added once.

All 120 tests in the three affected files pass, plus the shared-parser and airflow-core configuration secret tests (unaffected, confirming the constant refactor didn't change _get_custom_secret_backend()'s behavior).

---

Drafted-by: Claude Code (Sonnet 5) (no human review before posting)

[dheerenmohta]

CodeQL flagged 4 high-severity "clear-text logging of sensitive information" alerts introduced by the previous commit here, which was blocking the required check despite the approvals above.

Root cause: that commit introduced a new lookup table named SECRETS_BACKEND_CONFIG_KEYS. CodeQL's clear-text-logging query treats any value sourced from an identifier containing "secret" as sensitive data, so the (section, key) config-coordinate strings it produces (e.g. "secrets"/"backend") got flagged wherever they later reach a log.warning(...) call in _get_custom_secret_backend() and the generic config lookup — even though those strings are just config locations, never the actual secret value they point at.

Pushed a follow-up commit renaming the constant to CUSTOM_BACKEND_CONFIG_KEYS, which removes the name-based heuristic trigger with no behavior change (120 CLI tests + 68 shared-parser tests pass).

---

Drafted-by: Claude Code (Sonnet 5) (no human review before posting)

[potiuk]

Thanks — all three follow-ups are addressed, and the constant in the shared parser is a better answer to the drift concern than the comment I suggested: _get_custom_secret_backend() and the CLI now read the same (section, key) pairs, so the next backend source can't be added to one and missed in the other. I traced the _get_custom_secret_backend() refactor including the worker → general fallback, and it behaves identically. Approving.

Two optional notes, neither blocking:

• On the CodeQL rename: those alerts are genuine false positives (the values are config coordinates, not secrets), so renaming works, but dismissing the alerts as "false positive" in the Security tab is the more usual route and would let the constant keep the more descriptive name. Either is fine — your comment explains the choice, which is what matters.
• AGENTS.md prefers conf_vars as a decorator when the values are fixed; the six with conf_vars({...}): blocks here all use fixed values.

---

This review was drafted by an AI-assisted tool and
confirmed by an Apache Airflow maintainer. The maintainer
approving this PR has read the findings and signed off. If
something feels off, please reply on the PR and a maintainer
will follow up.

More on how Apache Airflow handles maintainer review:
contributing-docs/05_pull_requests.rst.

---

Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting