Skip to content

wrangler containers info: no --json flag (asymmetric with list / instances #14035

@alexminza

Description

@alexminza

What versions & operating system are you using?

Wrangler 4.93.0 on macOS 25.5.0 (Darwin). Verified against the source at pinned tag wrangler@4.93.0 — the behaviour described below is reproducible from the source as well as the CLI help output.

npx envinfo --system --npmPackages '{wrangler,create-cloudflare,miniflare,@cloudflare/*}' --binaries
  System: macOS 25.5.0 (arm64)
  Binaries: Node 22.x, npm 10.x, wrangler 4.93.0

Please provide a link to a minimal reproduction

No external repro needed — the behaviour is intrinsic to wrangler's own CLI surface and is reproducible with any container application the user owns:

# Sibling commands expose --json directly:
wrangler containers list --help     | grep -- --json
#       --json      Return output as JSON  [boolean] [default: false]
wrangler containers instances --help | grep -- --json
#       --json      Return output as JSON  [boolean] [default: false]

# `wrangler containers info` does NOT expose --json:
wrangler containers info --help     | grep -- --json
# (no match)

# JSON output for `info` is only reachable via implicit non-TTY detection:
CI=true wrangler containers info <APPLICATION_ID>   # → JSON
wrangler containers info <APPLICATION_ID>            # → interactive TUI / banner

Describe the Bug

wrangler containers info <ID> has no explicit --json flag at wrangler@4.93.0, while the two sibling commands in the same containers namespace — wrangler containers list and wrangler containers instances — both expose --json as a documented boolean flag. JSON output from info is reachable only via the implicit non-TTY / CI=true / WRANGLER_LOG_SANDBOXED_OUTPUT code path.

Source at the pinned tag (packages/wrangler/src/containers/containers.ts § infoYargs + infoCommand):

export function infoYargs(args: CommonYargsArgv) {
  return args.positional("ID", {
    describe: "id of the containers to view",
    type: "string",
  });
  // ← no `.option("json", { ... })`
}

export async function infoCommand(
  infoArgs: StrictYargsOptionsToInterface<typeof infoYargs>,
  _config: Config,
) {
  // …
  if (isNonInteractiveOrCI()) {
    const application = await ApplicationsService.getApplication(infoArgs.ID);
    logger.json(application);
    return;
  }
  // … interactive TUI path via inputPrompt …
}

The data is already serialised by logger.json(application); only the CLI flag exposing that path is missing.

Why this matters for scriptable use:

  1. Asymmetric with siblings. wrangler containers list --json and wrangler containers instances --json give scripts a deterministic, machine-readable output shape. wrangler containers info requires the script to set CI=true (or rely on the calling shell already being non-interactive) — neither is documented and both are easy to miss when porting a one-off command into a script.
  2. Failure mode is silent and ugly. Without CI=true, wrangler containers info <ID> prints a TUI prompt or a human banner table on stdout. A consumer pipe like wrangler containers info <ID> | jq … then dies with jq: parse error: Invalid numeric literal …, with no hint that the wrangler subcommand was the cause.
  3. Discoverability via --help is wrong. An operator inspecting wrangler containers info --help sees no JSON-output affordance and reasonably concludes the command doesn't support JSON at all — even though it does, gated on environment detection.
  4. Documentation drift. The Cloudflare Containers docs (https://developers.cloudflare.com/containers/) cover wrangler containers list / instances with explicit --json examples; the asymmetry for info isn't called out.

This is a CLI-surface consistency bug, not a missing feature — the JSON output already works, it just isn't reachable via an explicit flag the way the sibling commands are.

Please provide any relevant error logs

Concrete failure observed when scripting against info without CI=true:

$ wrangler containers info <APPLICATION_ID> | jq '.configuration.authorized_keys // []'
jq: parse error: Invalid numeric literal at line 1, column 11

Root cause: wrangler emitted the human-readable banner / version notice on stdout (not the API response), jq parsed the first banner line, choked at the first non-numeric character.

Workaround a downstream script needs to apply:

CI=true wrangler containers info "${ID}" | jq '.'   # works

Proposed fix

Add an explicit --json boolean flag to infoYargs that forces the same logger.json(application) path that isNonInteractiveOrCI() currently gates on. Roughly:

export function infoYargs(args: CommonYargsArgv) {
  return args
    .positional("ID", {
      describe: "id of the containers to view",
      type: "string",
    })
    .option("json", {
      describe: "Return output as JSON",
      type: "boolean",
      default: false,
    });
}

export async function infoCommand(
  infoArgs: StrictYargsOptionsToInterface<typeof infoYargs>,
  _config: Config,
) {
  // …
  if (infoArgs.json || isNonInteractiveOrCI()) {
    const application = await ApplicationsService.getApplication(infoArgs.ID);
    logger.json(application);
    return;
  }
  // … existing interactive TUI path …
}

This matches the shape of instancesArgs / listArgs exactly. Behaviour for existing callers is unchanged: the implicit non-TTY / CI=true JSON path still works, plus the new explicit flag.

Alternatives considered

  1. Leave as-is; document the CI=true workaround. Rejected — discoverability via --help is the natural surface; documenting an environment-variable workaround for one command in a CLI namespace that otherwise uses explicit flags is operator-hostile and asymmetric for no benefit.
  2. Add the --format json|pretty shape used by wrangler secret list. Rejected — the sibling commands in the same namespace (containers list, containers instances) use --json boolean; adopting --format here would itself introduce inconsistency.

Related upstream items

  • wrangler containers list — already exposes --json; precedent for the proposed shape.
  • wrangler containers instances — already exposes --json; precedent for the proposed shape.
  • No prior issue or PR found via gh search issues|prs on cloudflare/workers-sdk against terms "wrangler containers info json", "containers info --json", or "wrangler containers --json" as of filing.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No fields configured for Bug.

    Projects

    Status
    In Review

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions