CircleCI-Public / CircleCI-Public/chunk-cli

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

Open
#432 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
86
Forks
41
Avg merge
3d 7h
Merged PRs (30d)
56

Description

`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 --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

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

chunk task run --definition --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.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with internal/cmd/task.go and internal/task/task.go to trace the --new-branch default and trigger payload, then review acceptance/task_test.go for existing expectations. Resolve the product decision first, implement the selected guard, and update docs/CLI.md, help text, and tests so the commit target and confirmation behavior are explicit.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
cli, documentation
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.