Fix debug program args after --

[juyrjola]

Summary

This fixes dap debug when the debugged program needs its own CLI arguments.

Before this change, Cobra treated arguments after -- as extra positional arguments for dap debug itself. That caused commands like:

dap debug script.py --break script.py:10 -- value

to fail during CLI argument validation instead of starting a debug session and forwarding value to the target script.

Root Cause

debug used cobra.MaximumNArgs(1), which counted arguments after -- toward the command's positional arg limit.

The command also reconstructed forwarded program args from a different slice than the one used for validation, which made the parsing logic brittle around the separator.

Fix

• Validate only the arguments before --
• Use that same pre-separator slice to determine the script path
• Forward the post-separator slice directly as ProgramArgs

Tests

• Added an end-to-end regression test for a Python script that requires a forwarded argument
• Verified go test ./... passes locally
• The new Python-specific E2E test skips unless debugpy is installed

[qodo-free-for-open-source-projects]

Review Summary by Qodo

Fix debug command to properly handle program arguments after --

🐞 Bug fix

Walkthroughs

Description

• Fix argument parsing to handle program args after -- separator
• Validate only pre-separator args, forward post-separator args to debugged program
• Add end-to-end regression test for Python script with forwarded arguments

Diagram

flowchart LR
  A["CLI args with --"] --> B["Split at -- separator"]
  B --> C["Validate pre-separator args"]
  B --> D["Forward post-separator args"]
  C --> E["Set script path"]
  D --> F["Set ProgramArgs"]
  E --> G["Start debug session"]
  F --> G

Loading

File Changes

1. cli.go 🐞 Bug fix +20/-9

Fix argument parsing for program args after separator

• Replace cobra.MaximumNArgs(1) with custom validation that only counts pre-separator arguments
• Extract script arguments before -- separator in both validation and execution paths
• Fix ProgramArgs extraction to use pre-separator slice directly instead of cmd.Flags().Args()
• Add example in command documentation showing program args usage with --

cli.go

---

2. e2e_test.go 🧪 Tests +42/-0

Add regression test for program arguments

• Add new test TestE2E_DebugPython_WithProgramArgs that verifies debug command with forwarded
 arguments
• Test creates Python script requiring CLI argument, passes it after -- separator
• Validates breakpoint is hit and forwarded argument appears in debugger locals
• Test skips if debugpy is not installed

e2e_test.go

---

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 📐 Spec deviations (0)

1. Breakpoint before assignment 🐞 Bug ✓ Correctness

Description

TestE2E_DebugPython_WithProgramArgs sets a breakpoint on the same line where value is assigned,
but then asserts value is present in locals at the breakpoint stop; locals are collected at the
stop location before executing the current line, so value will not exist yet.

Code

e2e_test.go[R221-239]

+	cmd := exec.Command(env.binary,
+		"--socket", env.socketPath,
+		"debug", scriptPath,
+		"--break", scriptPath+":6",
+		"--",
+		"example-value",
+	)
+	cmd.Dir = projectRoot(t)
+	out, err := cmd.CombinedOutput()
+	if err != nil {
+		t.Fatalf("debug with program args failed: %v\n%s", err, out)
+	}
+
+	if !strings.Contains(string(out), "Stopped: breakpoint") {
+		t.Errorf("expected breakpoint stop, got:\n%s", out)
+	}
+	if !strings.Contains(string(out), "value (str) = 'example-value'") {
+		t.Errorf("expected parsed CLI arg in locals, got:\n%s", out)
+	}

Evidence

The test-generated script assigns value on line 6 and prints it on line 7, but the test breaks at
line 6 and immediately checks for value in locals. Existing E2E behavior demonstrates locals are
captured before executing the current line (it breaks on a line where variables were assigned
earlier, and only observes newly-assigned variables after a step).

e2e_test.go[200-239]
e2e_test.go[114-140]
testdata/python/simple.py[1-4]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`TestE2E_DebugPython_WithProgramArgs` breaks on the `value = args.value` line and then asserts `value` exists in locals. At a line breakpoint, execution typically stops before that assignment runs, so `value` won’t be in locals.

### Issue Context
The test intends to verify that arguments after `--` are forwarded to the debugged program and observable in debugger context.

### Fix Focus Areas
- e2e_test.go[200-239]

### Suggested fix
Change the breakpoint to the next line (the `print(value)` line) so `value` is assigned before locals are collected, e.g. change `--break scriptPath+":6"` to `--break scriptPath+":7"`. Alternatively, keep the breakpoint at `:6` but add a subsequent `step` command and assert on that output instead.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[qodo-free-for-open-source-projects]

1. Breakpoint before assignment 🐞 Bug ✓ Correctness

TestE2E_DebugPython_WithProgramArgs sets a breakpoint on the same line where value is assigned,
but then asserts value is present in locals at the breakpoint stop; locals are collected at the
stop location before executing the current line, so value will not exist yet.

Agent Prompt

### Issue description
`TestE2E_DebugPython_WithProgramArgs` breaks on the `value = args.value` line and then asserts `value` exists in locals. At a line breakpoint, execution typically stops before that assignment runs, so `value` won’t be in locals.

### Issue Context
The test intends to verify that arguments after `--` are forwarded to the debugged program and observable in debugger context.

### Fix Focus Areas
- e2e_test.go[200-239]

### Suggested fix
Change the breakpoint to the next line (the `print(value)` line) so `value` is assigned before locals are collected, e.g. change `--break scriptPath+":6"` to `--break scriptPath+":7"`. Alternatively, keep the breakpoint at `:6` but add a subsequent `step` command and assert on that output instead.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[srinji-kaggss]

Independent confirmation, verified 2026-08-03 on both dap v0.4.2 (Homebrew) and current main (go build ./cmd/dap, cobra v1.10.2):

$ dap debug /tmp/argtest.py --break /tmp/argtest.py:2 -- one two
Error: accepts at most 1 arg(s), received 3

Root cause is exactly what this PR describes: cobra.MaximumNArgs(1) counts post--- args (cli.go debug command, and the same Args: line also sits on dap step, which has no program-args escape hatch — its [in|out|over] positional is the only one, so the validation bug there is latent, not reachable).

This PR is still unmerged as of today, so dap debug <script> -- <program args> remains broken on main. For anyone blocked meanwhile, a drop-in workaround is a dash-aware validator replacing both cobra.MaximumNArgs(1) sites:

Args: func(cmd *cobra.Command, args []string) error {
    if dashIdx := cmd.ArgsLenAtDash(); dashIdx >= 0 {
        args = args[:dashIdx]
    }
    if len(args) > 1 {
        return fmt.Errorf("accepts at most 1 arg(s), received %d", len(args))
    }
    return nil
},

Verified end-to-end: with that patch I ran a full lldb-dap session against a Rust test binary (dap debug <bin> --backend lldb-dap --break file.rs:144 -- --exact <test> --nocapture --test-threads=1) — breakpoints, eval, step, continue all worked. Happy to test this PR's branch against the same scenarios once it lands.