Skip to content

[scanner] attach: --dangerous silently no-ops for --cli=gemini and --cli=aider (no DANGEROUS_FLAGS mapping) #360

Closed

Description

@hivecommons-hive

Summary

pluk attach <session> --cli=gemini --dangerous and pluk attach <session> --cli=aider --dangerous accept the flag but pass nothing to the CLI. resolveDangerousFlag() in src/attach.ts (lines 163-172) maps only claude, copilot, codex, goose and omp; for any other name it returns '' and the new-session path logs no dangerous/auto flag known for cli=<cli>, skipping — but only through the verbose-gated log() (attach.ts:283-285), so a non-verbose user sees the normal Starting gemini: gemini line and never learns the flag was dropped.

Both CLIs are listed as supported in README.md §"Supported CLIs" (line 291) and both have an auto-approve switch:

  • Gemini CLI: --yolo (alias -y; newer releases also accept --approval-mode yolo)
  • Aider: --yes-always

Evidence

src/attach.ts:163-172 — the DANGEROUS_FLAGS map inside resolveDangerousFlag() has exactly five keys:

    claude: '--dangerously-skip-permissions',
    copilot: '--allow-all-tools',
    codex: '--full-auto',
    goose: '--non-interactive',
    omp: '--approval-mode yolo',

and the function returns DANGEROUS_FLAGS[cli] ?? ''. The README --dangerous row (line 133) lists the same five CLIs, so the pin test added in #230 keeps README and code in step but does not require every bundled pattern set (patterns/*.patterns — 7 CLIs) to have a mapping.

Expected

  1. Add gemini: '--yolo' and aider: '--yes-always' to DANGEROUS_FLAGS, update the README --dangerous row to match (the test: pin README --dangerous row to attach.ts DANGEROUS_FLAGS #230 pin test will enforce it), and add a changelog.d/fixed-<n>.md fragment.
  2. Make the "no dangerous/auto flag known" case a real console.error('Warning: ...') rather than a verbose-only log, so a future unmapped CLI is not silently dropped.
  3. Add a test asserting every CLI in listAvailableCLIs(bundledPatternsDir()) / BUILTIN_PATTERNS has a DANGEROUS_FLAGS entry, so the gap cannot reopen when a new pattern file is added.

Decision taken by hive: --yolo is chosen for Gemini over --approval-mode yolo because it is accepted by every Gemini CLI release that has an auto-approve mode and is a single token.

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

Activity

  1. added
    bugSomething isn't working
    agent/scannerCreated by Hive for agent-filed issue provenance
    on Oct 24, 2026
  2. added
    help wantedDenotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.
    on Oct 24, 2026
  3. hivecommons-hive commented on Oct 24, 2026

    @hivecommons-hive
    ContributorAuthor

    Folded finding. This was filed as a separate issue, but 1 open agent-filed issue (plus 17 closed as completed in the last 14 days) already cite src/attach.ts, so it was folded into the oldest of them instead of opening another. Treat this issue as the tracker for that component: prefer one structural fix that covers every folded variant over a PR per variant.

    Review backlog (correctness): Existing-session path stays silent for a CLI with no DANGEROUS_FLAGS entry

    Filed from an out-of-scope finding in the Hive review of PR #361.

    PR: #361 (#361)
    Perspective: correctness
    Severity: low (P3)
    Evidence: src/attach.ts:355 (

    if (opts.dangerouslySkipPermissions) {
    )
    Finding: Existing-session path stays silent for a CLI with no DANGEROUS_FLAGS entry

    In the sessionExists branch, if (dangerFlag) guards the only warning, so pluk attach <existing> --cli=<unmapped> --dangerous still emits nothing (pre-existing; #360 only asked for the new-session path, which this PR fixes at src/attach.ts:346). Now that every bundled CLI is mapped and the matrix test enforces it, this only affects ad-hoc --cli=<binary> names.

    Fingerprint: 636c4c2301b749fbc48ed31a3e6349a79b0437069ae8576ed168c38bc3fb0da6

    filed by Hive review backlog


    Folded finding. This was filed as a separate issue, but 1 open agent-filed issue (plus 17 closed as completed in the last 14 days) already cite src/attach.ts, so it was folded into the oldest of them instead of opening another. Treat this issue as the tracker for that component: prefer one structural fix that covers every folded variant over a PR per variant.

    Review backlog (intent-alignment): Existing-session path stays silent for unmapped CLI with --dangerous

    Filed from an out-of-scope finding in the Hive review of PR #361.

    PR: #361 (#361)
    Perspective: intent-alignment
    Severity: low (P3)
    Evidence: src/attach.ts:356 (

    const dangerFlag = resolveDangerousFlag(cli);
    )
    Finding: Existing-session path stays silent for unmapped CLI with --dangerous

    In the sessionExists branch, resolveDangerousFlag() returning '' produces no warning at all (only the non-empty case at attach.ts:356-359 warns). Issue #360 scopes the warning to the new-session path, so this PR satisfies it; the re-attach path with an unmapped CLI remains a silent no-op for later work.

    Fingerprint: 6d5ed4863e946f286bdcf5d0eeb1a149f0cdb73a21917d7b176d1ba5563c14da

    filed by Hive review backlog

  4. hivecommons-hive commented on Oct 24, 2026

    @hivecommons-hive
    ContributorAuthor

    Additional finding (folded in — same file, possibly a different problem). Raised in the Hive review of PR #361 (#361) and folded into this issue because it cites src/attach.ts, which this issue already covers. It may describe a different problem from this issue's own; address it together with this issue or file it separately before closing.

    Review backlog (correctness): Existing-session path stays silent for a CLI with no DANGEROUS_FLAGS entry

    • Existing-session path stays silent for a CLI with no DANGEROUS_FLAGS entry (src/attach.ts:355)

    Perspective: correctness
    Severity: low (P3)
    Evidence: src/attach.ts:355 (

    if (opts.dangerouslySkipPermissions) {
    )
    Finding: Existing-session path stays silent for a CLI with no DANGEROUS_FLAGS entry

    In the sessionExists branch, if (dangerFlag) guards the only warning, so pluk attach <existing> --cli=<unmapped> --dangerous still emits nothing (pre-existing; #360 only asked for the new-session path, which this PR fixes at src/attach.ts:346). Now that every bundled CLI is mapped and the matrix test enforces it, this only affects ad-hoc --cli=<binary> names.

    Fingerprint: 636c4c2301b749fbc48ed31a3e6349a79b0437069ae8576ed168c38bc3fb0da6

    filed by Hive review backlog

  5. hivecommons-hive commented on Oct 24, 2026

    @hivecommons-hive
    ContributorAuthor

    Additional finding (folded in — same file, possibly a different problem). Raised in the Hive review of PR #361 (#361) and folded into this issue because it cites src/attach.ts, which this issue already covers. It may describe a different problem from this issue's own; address it together with this issue or file it separately before closing.

    Review backlog (intent-alignment): Existing-session path stays silent for unmapped CLI with --dangerous

    • Existing-session path stays silent for unmapped CLI with --dangerous (src/attach.ts:356)

    Perspective: intent-alignment
    Severity: low (P3)
    Evidence: src/attach.ts:356 (

    const dangerFlag = resolveDangerousFlag(cli);
    )
    Finding: Existing-session path stays silent for unmapped CLI with --dangerous

    In the sessionExists branch, resolveDangerousFlag() returning '' produces no warning at all (only the non-empty case at attach.ts:356-359 warns). Issue #360 scopes the warning to the new-session path, so this PR satisfies it; the re-attach path with an unmapped CLI remains a silent no-op for later work.

    Fingerprint: 6d5ed4863e946f286bdcf5d0eeb1a149f0cdb73a21917d7b176d1ba5563c14da

    filed by Hive review backlog

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    agent/reviewerCreated by Hive for agent-filed issue provenanceagent/scannerCreated by Hive for agent-filed issue provenancebugSomething isn't workinghelp wantedDenotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.hive/claimed-by-scanner

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions