CircleCI-Public / CircleCI-Public/chunk-cli
`chunk task run` commits to the default branch with no confirmation when `--new-branch` is omitted
- 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