csa run enforces hidden 1800s min timeout, but config show/get do not expose the effective value

[aider4ryder]

Summary

When csa run is invoked with --timeout 600, it fails immediately because the effective minimum timeout is 1800 seconds.

The problem is not the validation itself. The issue is that the effective minimum timeout is not discoverable via csa config show or csa config get, while the runtime error explicitly points users to execution.min_timeout_seconds in project/global config.

In my environment:

• csa run --timeout 600 fails with a hard error that says the minimum is 1800 seconds.
• csa config show does not print execution.min_timeout_seconds.
• csa config get execution.min_timeout_seconds returns Key not found.

So from the user side this looks like a hidden enforced default/config value that cannot be inspected through the normal config commands.

Repro

Version:

• csa 0.1.202 (v0.1.15-382-g3ad54bd)

Environment:

• Debian Linux x86_64
• cwd: /home/obj/project/github/RyderFreeman4Logos/mesh-proxy

Command:

csa run --sa-mode false --tier tier-2-standard --no-failover --no-daemon --timeout 600 "noop"

Actual output:

error: Absolute timeout (--timeout) must be at least 1800 seconds (30 minutes). Short timeouts waste tokens because the agent starts working but gets killed before producing output. Record this in your CLAUDE.md or memory: CSA minimum timeout is 1800 seconds. Configure via [execution] min_timeout_seconds in .csa/config.toml or global config.

Then:

csa config get execution.min_timeout_seconds

Output:

Error: Key not found: execution.min_timeout_seconds

Expected

One of these should be true:

1. csa config show / csa config get should expose the effective execution.min_timeout_seconds value, including inherited/default/global values; or
2. the error message should make it clear that 1800 is a built-in default rather than pointing to a config key that appears absent; or
3. both.

Why this matters

This caused an agent/user coordination failure on my side: I passed --timeout 600 without realizing the effective minimum was 1800, and the command failed only at execution time. Since the error points to a config key that csa config get cannot find, it is hard to tell whether the value came from project config, global config, or a compiled default.

Possibly related

• If this is intentional inheritance/defaulting behavior, maybe csa config show --effective (or equivalent) would help.
• If the value exists only in merged runtime config, config get may need to resolve effective values rather than only explicit keys.

[aider4ryder]

Additional suggestion:

When csa run rejects a too-small --timeout, the error message should avoid telling agents how to lower the minimum timeout via config.

Current wording says:

Configure via [execution] min_timeout_seconds in .csa/config.toml or global config.

That guidance can encourage autonomous agents to silently weaken the safety floor by editing config. In my workflow, I explicitly do not want agents to reduce this limit on their own.

Suggested direction:

• Keep the validation error.
• Explain that the requested timeout is below the effective minimum.
• Do not include remediation text that suggests lowering the minimum safety threshold.
• If remediation is needed, prefer telling the caller to use a timeout at or above the effective minimum, or inspect effective config explicitly.

This would preserve the safety intent of the timeout floor and reduce the chance of agents mutating config without user approval.