`chunk task run` commits to the default branch with no confirmation when `--new-branch` is omitted

[hidetaka-cci]

chunk task run treats --new-branch as opt-in (false by default). When the flag is omitted, the CLI sends create-new-branch: false and the Chunk agent may commit directly to the branch configured as default_branch in .chunk/run.json (often main).

There is no interactive confirmation prompt and no --yes / --force-style acknowledgement for this path. First-time users who follow the happy path (task config → task run) can therefore push agent-authored commits onto a protected or shared default branch without realizing that is the default.

Current behavior

1. chunk task config writes .chunk/run.json with a default_branch (commonly main).
2. chunk task run --definition <name> --prompt "..." (no --new-branch) triggers a run with create-new-branch: false.
3. The agent commits on that default branch when the run succeeds.
4. Help text documents --new-branch but does not warn that omitting it targets the default branch with no confirmation.

Relevant code:

• internal/cmd/task.go — --new-branch defaults to false; no confirmation prompt
• internal/task/task.go — sends "create-new-branch": params.NewBranch in the trigger payload

Impact

• Who: Anyone running task run without --new-branch, especially users whose default_branch is a shared or protected branch.
• Workaround: Always pass --new-branch, or point default_branch at a disposable branch before running.
• Cost: Accidental commits on main / the repo default branch; hard to undo in teams with branch protection or required reviews.

Reproduction

chunk auth set circleci
chunk task config
# Completes with default_branch typically set to main (or the project default)

chunk task run --definition <name> --prompt "Add a trivial comment"
# No confirmation is shown.
# create-new-branch is false in the trigger payload.
# On success, the agent may commit directly to default_branch.

Verified against CLI 0.7.107. Acceptance coverage in acceptance/task_test.go asserts the default payload uses create-new-branch: false and that --new-branch flips it to true.

Expected behavior

Direct commits to the configured default branch should not be the silent default for interactive local use. Safer options (product decision needed):

1. Safer default: Treat --new-branch as the default (true), and require an explicit opt-in to commit on the existing branch (e.g. --commit-to-branch / --no-new-branch).
2. Confirm when risky: If the target branch equals default_branch (or a well-known protected name such as main / master), prompt for confirmation on interactive TTYs, with a non-interactive escape hatch such as --yes.
3. Document clearly: At minimum, task run --help and docs/CLI.md should state that omitting --new-branch commits on default_branch with no prompt — but documentation alone does not remove the footgun.

Proposed fix

Product decision first, then implementation. Suggested checklist:

• Decide whether the safe default is “always create a new branch” or “confirm before committing to default_branch”
• Implement the chosen guard in chunk task run (default flip and/or TTY confirmation + --yes)
• Update help text and docs/CLI.md to describe the commit target and any confirmation behavior
• Update unit / acceptance tests that currently expect create-new-branch: false by default

Notes

This issue is about the CLI default and UX. The API already accepts create-new-branch; the gap is that chunk task run defaults it to false and never asks the user to confirm.