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:
- 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.
- 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.
- 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.
- 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
- 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.
- 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.
What versions & operating system are you using?
Wrangler
4.93.0on macOS 25.5.0 (Darwin). Verified against the source at pinned tagwrangler@4.93.0— the behaviour described below is reproducible from the source as well as the CLI help output.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:
Describe the Bug
wrangler containers info <ID>has no explicit--jsonflag atwrangler@4.93.0, while the two sibling commands in the samecontainersnamespace —wrangler containers listandwrangler containers instances— both expose--jsonas a documented boolean flag. JSON output frominfois reachable only via the implicit non-TTY /CI=true/WRANGLER_LOG_SANDBOXED_OUTPUTcode path.Source at the pinned tag (
packages/wrangler/src/containers/containers.ts§infoYargs+infoCommand):The data is already serialised by
logger.json(application); only the CLI flag exposing that path is missing.Why this matters for scriptable use:
wrangler containers list --jsonandwrangler containers instances --jsongive scripts a deterministic, machine-readable output shape.wrangler containers inforequires the script to setCI=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.CI=true,wrangler containers info <ID>prints a TUI prompt or a human banner table on stdout. A consumer pipe likewrangler containers info <ID> | jq …then dies withjq: parse error: Invalid numeric literal …, with no hint that the wrangler subcommand was the cause.--helpis wrong. An operator inspectingwrangler containers info --helpsees no JSON-output affordance and reasonably concludes the command doesn't support JSON at all — even though it does, gated on environment detection.wrangler containers list/instanceswith explicit--jsonexamples; the asymmetry forinfoisn'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
infowithoutCI=true:Root cause: wrangler emitted the human-readable banner / version notice on stdout (not the API response),
jqparsed the first banner line, choked at the first non-numeric character.Workaround a downstream script needs to apply:
Proposed fix
Add an explicit
--jsonboolean flag toinfoYargsthat forces the samelogger.json(application)path thatisNonInteractiveOrCI()currently gates on. Roughly:This matches the shape of
instancesArgs/listArgsexactly. Behaviour for existing callers is unchanged: the implicit non-TTY /CI=trueJSON path still works, plus the new explicit flag.Alternatives considered
CI=trueworkaround. Rejected — discoverability via--helpis 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.--format json|prettyshape used bywrangler secret list. Rejected — the sibling commands in the same namespace (containers list,containers instances) use--jsonboolean; adopting--formathere 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.gh search issues|prsoncloudflare/workers-sdkagainst terms "wrangler containers info json", "containers info --json", or "wrangler containers --json" as of filing.