From 4639a5820c659adaf04b32647fbaa26ba922a5ed Mon Sep 17 00:00:00 2001 From: Yeachan-Heo Date: Thu, 21 May 2026 05:01:10 +0000 Subject: [PATCH] docs(roadmap): add config env unsupported flag hang --- ROADMAP.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ROADMAP.md b/ROADMAP.md index 003897a1..57cb71e9 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -6605,3 +6605,5 @@ Original filing (2026-04-18): the session emitted `SessionStart hook (completed) 524. **`--dangerously-skip-permissions` is accepted after non-mutating diagnostic subcommands and changes their reported permission mode, so a capability-escalation flag can be silently treated as relevant control-plane state for `status`/`version`/`config`/`doctor`/`sandbox` instead of being scoped to prompt/runtime execution** — dogfooded 2026-05-21 from the `#clawcode-building-in-public` 04:00 UTC nudge on `/home/bellman/Workspace/claw-code-pr2967` with branch/origin `docs/roadmap-workdir-provenance@88c4412` and binary `./rust/target/debug/claw` built from source SHA `25d663d`. Clean-home probes with a minimal `.claw.json`: `claw status --dangerously-skip-permissions` exits 0 and reports `Permission mode danger-full-access`; `claw version --dangerously-skip-permissions`, `claw config env --dangerously-skip-permissions`, `claw doctor --dangerously-skip-permissions`, and `claw sandbox --dangerously-skip-permissions` also exit 0. Prefix form `claw --dangerously-skip-permissions status` behaves the same. This flag is documented as “Skip all permission checks” and is meaningful for model/tool execution, not read-only diagnostics like version/config/status. Accepting it everywhere makes diagnostic output look like an authority escalation happened and gives wrappers no way to detect accidental dangerous flag bleed-through from prompt invocations into health checks. **Required fix shape:** (a) define command-specific acceptance for capability-changing flags; (b) reject `--dangerously-skip-permissions` on non-executing diagnostics (`version`, `status`, `config`, `doctor`, `sandbox`, maybe `system-prompt`) with bounded `kind:"unsupported_flag_for_command"`, or explicitly mark it ignored with `ignored_flags` metadata and never report `danger-full-access` for non-execution commands; (c) keep the flag valid only for prompt/REPL/runtime paths where permission checks actually apply; (d) add clean-home regressions for both trailing and prefix placement across diagnostics and valid prompt usage; (e) ensure status distinguishes configured/default permission mode from an execution override. **Why this matters:** permission-mode reporting is a control-plane trust signal. If a dangerous runtime escape hatch is silently accepted by local diagnostics, users and orchestrators can misread a harmless status probe as running under danger-full-access, or fail to catch dangerous flag leakage before executing real tool work. Source: gaebal-gajae dogfood response to Clawhip message `1506869175522693160` on 2026-05-21. 525. **`--allow-broad-cwd` is accepted after normal diagnostic subcommands even when the current directory is not broad, and `status` reports `danger-full-access`, so a broad-directory bypass flag silently bleeds into unrelated health/config surfaces instead of being scoped to the broad-cwd guard** — dogfooded 2026-05-21 from the `#clawcode-building-in-public` 04:30 UTC nudge on `/home/bellman/Workspace/claw-code-pr2967` with branch/origin `docs/roadmap-workdir-provenance@0651749` and binary `./rust/target/debug/claw` built from source SHA `25d663d`. Clean-home probes from a narrow temp workspace with a minimal `.claw.json`: `claw status --allow-broad-cwd`, `claw version --allow-broad-cwd`, `claw doctor --allow-broad-cwd`, `claw sandbox --allow-broad-cwd`, and prefix `claw --allow-broad-cwd status` all exit 0; `status` reports `Permission mode danger-full-access`. `claw config env --allow-broad-cwd` is worse: it timed out after 6s with `stdout=0`/`stderr=0`, showing the same trailing-flag swallowing path can still hit a silent hang on one config subcommand. `--allow-broad-cwd` exists to explicitly bypass the broad-cwd safety guard when running from `/`, `$HOME`, `/tmp`, etc.; it should not be a no-op/permission-shaped accepted flag on `version`, `doctor`, `sandbox`, or config inspection from an ordinary project directory. **Required fix shape:** (a) scope `--allow-broad-cwd` to the broad-cwd preflight only and expose it in diagnostics as `broad_cwd_override:true` only when the cwd is actually broad; (b) reject it on non-broad cwd or non-workspace-executing diagnostics with bounded `kind:"unsupported_flag_for_command"` / `kind:"unnecessary_broad_cwd_override"`; (c) never let this flag affect or appear as `permission_mode`; (d) fix the `config env --allow-broad-cwd` trailing-flag hang with the same command-specific flag metadata used for #523/#524; (e) add clean-home regressions for narrow cwd, `/`, `$HOME`, and `/tmp` across `status`, `doctor`, `config env`, and valid prompt/resume paths. **Why this matters:** broad-cwd override is a blast-radius escape hatch. If automation accidentally carries it into every diagnostic call, the CLI should either ignore it with explicit metadata or reject it, not make status look like a danger-full-access runtime nor hang a config probe. Source: gaebal-gajae dogfood response to Clawhip message `1506876721666719805` on 2026-05-21. + +526. **`config env` swallows unsupported trailing runtime/session flags into a zero-byte hang while sibling diagnostics reject the same flags with `cli_parse`, so config inspection has a unique prompt-fallback/argument-drain bug** — dogfooded 2026-05-21 from the `#clawcode-building-in-public` 05:00 UTC nudge on `/home/bellman/Workspace/claw-code-pr2967` with branch/origin `docs/roadmap-workdir-provenance@24ccc6e` and binary `./rust/target/debug/claw` built from source SHA `25d663d`. Clean-home probes from a minimal temp workspace compared the same unsupported trailing flags across `status`, `version`, `config env`, `doctor`, and `sandbox`. For `--resume`, `--max-turns`, `--continue`, and `--verbose`, the non-config diagnostics all returned bounded `cli_parse` errors like `unrecognized argument '--resume' for subcommand 'status'`. But `claw config env --resume`, `claw config env --max-turns`, `claw config env --continue`, and `claw config env --verbose` each timed out after 6s with `stdout=0`/`stderr=0`. This is the same family as #525's `config env --allow-broad-cwd` hang, but the broader sweep shows `config env` is the outlier parser path for multiple unsupported runtime/session flags, not just one safety override. **Required fix shape:** (a) give `config env` and all `config
` forms the same strict trailing-argument validation as `status`/`doctor`/`sandbox`; (b) reject unsupported flags before any config/runtime fallback with `kind:"cli_parse"` / `kind:"unsupported_flag_for_command"`, echoing the offending flag and valid config options; (c) centralize config-subcommand argument parsing so `config env`, `config model`, `config hooks`, and `config plugins` cannot drift; (d) add clean-home elapsed-time regressions for `config env --resume`, `--max-turns`, `--continue`, `--verbose`, `--allow-broad-cwd`, and a valid `config env --output-format json`; (e) audit whether the same hang exists for `config model/hooks/plugins` and close it in the same parser fix. **Why this matters:** `config env` is a support/debug surface users paste into issue reports. Unsupported flags should fail fast and visibly; a zero-byte hang makes config troubleshooting look like startup deadlock and hides the actual CLI typo. Source: gaebal-gajae dogfood response to Clawhip message `1506884276522848317` on 2026-05-21.