Configuration reference

Every key cxg 1.3.0 reads from a configuration file. Keys and defaults are the file cxg config generate wrote; descriptions are the doc comments on cxg’s own configuration structs, verbatim.

Pass a file with -c, --config <FILE>. Every section and every key is optional: an omitted one falls back to the compiled-in default shown here, and an empty file is a valid configuration.

The generated file

$ cxg config generate --output cert-x-gen.yaml

╭─────────────────────────────────────────────────────────────╮
│  📦 First run detected! Installing templates from GitHub...│
╰─────────────────────────────────────────────────────────────╯

[INF] Updated repositories: official

╭─────────────────────────────────────────────────────────────╮
│  ✅ Templates installed successfully!                       │
├─────────────────────────────────────────────────────────────┤
│  📊 Total: 169 templates                                     │
│     🐍 python: 69                                            │
│     📄 yaml: 50                                              │
│     🐹 go: 16                                                │
│     🐚 shell: 9                                              │
│     📜 javascript: 7                                         │
│     ⚙️ c: 5                                                 │
╰─────────────────────────────────────────────────────────────╯

Configuration generated: cert-x-gen.yaml

cert-x-gen.yaml then contains:

cert-x-gen.yaml

templates:
  directories: []
  timeout_secs: 30
network:
  timeout_secs: 10
  user_agent: cert-x-gen/1.3.0
  max_redirects: 5
  connection_pool_size: 100
  proxy: null
  rate_limit: 100
  headers: []
  cookies: []
execution:
  parallel_targets: 50
  parallel_templates: 10
  max_retries: 1
  retry_delay_secs: 1
  aggressive_mode: false
  stealth_mode: false

That is the whole surface. There is no key that config generate omits — the generator for this page fails if the struct carries a field the file does not.

templates:

Template configuration

Key	Type	Default	Description
directories	list of paths	[]	Template directories (for backward compatibility)
timeout_secs	integer	30	Template timeout (seconds)

network:

Network configuration

Key	Type	Default	Description
timeout_secs	integer	10	Request timeout (seconds)
user_agent	string	cert-x-gen/1.3.0	User agent string
max_redirects	integer	5	Maximum redirects
connection_pool_size	integer	100	Connection pool size
proxy	string, or null	null	Proxy URL
rate_limit	integer, or null	100	Rate limit (requests per second)
headers	list of [name, value] pairs	[]	Custom headers for HTTP requests
cookies	list of [name, value] pairs	[]	Cookies for authenticated scans

execution:

Execution configuration

Key	Type	Default	Description
parallel_targets	integer	50	Parallel target scanning
parallel_templates	integer	10	Parallel template execution per target
max_retries	integer	1	Maximum retries
retry_delay_secs	integer	1	Retry delay (seconds)
aggressive_mode	boolean (true / false)	false	Aggressive mode
stealth_mode	boolean (true / false)	false	Stealth mode

Keys cxg does not describe

The description column is a verbatim doc comment. For network.connection_pool_size, execution.aggressive_mode, execution.stealth_mode that comment only restates the key name, so cxg does not document what the key changes. Nothing here fills the gap by inference — see the CLI reference for the flags of the same name, which carry their own help text.

Values the loader refuses

Checked after the file parses. A rejected value fails the run with the message shown, rather than being clamped to something workable.

Key	Rejected when	Message
execution.parallel_targets	== 0	Parallel targets must be greater than 0
network.timeout_secs	== 0	Timeout must be greater than 0

File formats

The loader dispatches on the file extension, not on the contents: .yaml, .yml, .toml, .json. Any other extension is refused, whatever the file holds. cxg config generate --format writes the same set — see cxg config.

In the struct, not in the file

Fields cxg carries on its configuration types and deliberately does not read from or write to a file. Setting one in a config file does nothing — the key is not deserialized at all.

Field	Why
network.follow_redirects	Follow redirects. Not a config key: this is runtime plumbing for the --follow-redirects CLI flag, which unconditionally overwrites it (main.rs). Skipped from (de)serialization so a config file cannot set a value the flag ignores.

Sections this build no longer reads

cxg 1.3.0 tracks sandbox: as obsolete. A config that still carries one still loads — breaking the load would be the worse outcome — but never quietly:

cert-x-gen.yaml

network:
  timeout_secs: 20
sandbox:
  enabled: true

$ cxg config validate cert-x-gen.yaml
Configuration is loadable, but contains 1 obsolete section(s) with no effect: sandbox. See the warning above; remove them.

The warning itself goes to stderr:

warning: cert-x-gen.yaml contains a `sandbox:` section.

These settings never took effect. `enabled`, `memory_limit_mb`,
`cpu_limit_percent`, `network_access` and `filesystem_access` were
parsed and then ignored — no code path has ever read them to confine
anything. A config setting them was not protected by them.

Templates execute as ordinary child processes with the invoking user's
privileges and full network and filesystem access. Review templates
before running them.

Remove the `sandbox:` section from cert-x-gen.yaml. For real isolation, run cxg
itself inside a container or VM, as a non-privileged user.

(The `cxg sandbox` command is unrelated and still works — it manages
per-language dependency environments, not execution confinement.)

These keys never confined anything

A sandbox: section did not restrict template execution in any earlier version either. Templates run as ordinary child processes with the invoking user’s privileges and full filesystem and network access. Removing the keys changed nothing about what a template can do — see The template trust model.

Outcomes that are CLI-only

Keys that earlier versions accepted for these outcomes are gone. Each one parsed and then did nothing, so the flag was always the only thing that worked. The pairing is by outcome, not equivalence — read the flag’s own description before assuming it does exactly what the key claimed to:

No longer a config key	Use	How cxg describes that flag
output.min_severity	--severity	Filter templates by severity level. Example: –severity critical,high for a quick, high-signal assessment.
output.formats	--output-format	Output formats (comma-separated); several can be generated at once. Available: json (automation), csv (spreadsheet), sarif (CI/CD), html (visual report), markdown (docs).
output.output_dir	--output	Output file basename. The trailing extension (if any) is REPLACED by the chosen format’s extension — e.g. --output report.txt --output-format json writes report.json.
output.output_file	--output	Output file basename. The trailing extension (if any) is REPLACED by the chosen format’s extension — e.g. --output report.txt --output-format json writes report.json.
templates.enabled_languages	--template-language	Filter templates by programming language. Available: yaml, python, rust, shell, javascript, c, cpp, java, go, ruby, perl, php.