gmail labels: repeated --add (or --remove) flags only apply the last value

[yolo-sam]

Summary

When gmail labels <threadId> is invoked with the same flag repeated (e.g. --add A --add B), only the last value is applied — silently. The CLI returns ok, so callers think both labels were applied. Mixed flags (--add A --remove B) work correctly.

Reproduction

TEST_ID="<some thread id>"

# Make sure both labels are absent
gmail labels $TEST_ID --remove "•/🗂️ other"
gmail labels $TEST_ID --remove "•/FYI"

# Try to add both with one command
gmail labels $TEST_ID --add "•/🗂️ other" --add "•/FYI"
# → "$TEST_ID: ok"

# Verify
gmail search 'label:•/🗂️ other' --max 200 | grep -c "^$TEST_ID"  # → 0  ❌
gmail search 'label:•/FYI'        --max 200 | grep -c "^$TEST_ID"  # → 1  ✓

The first `--add` is silently dropped. Same behavior for repeated `--remove`:

gmail labels $TEST_ID --add "•/🗂️ other"
gmail labels $TEST_ID --add "•/FYI"
gmail labels $TEST_ID --remove "•/🗂️ other" --remove "•/FYI"
# → only "•/FYI" gets removed; "•/🗂️ other" stays

Mixed flag types work fine:

gmail labels $TEST_ID --add "•/🗂️ other" --remove "•/FYI"
# → both applied correctly

Expected

Either:

• All repeated flag values are applied (preferred — natural for label management), or
• The CLI errors out / warns when a flag is given twice, instead of silently dropping the earlier value.

Impact

Quietly broken bulk-classification: a session that runs --add "•/💳 money" --add "•/FYI" across dozens of threads ends up with category-less FYI threads, breaking the labeling invariant downstream tools assume.

Likely cause

Argument parser is using "last-wins" semantics on repeated flags instead of "append to array". Search the CLI for how --add / --remove are declared — switching to an array/append collector should fix it.

Workaround

Use separate single-flag invocations:

gmail labels $TEST_ID --add "•/🗂️ other"
gmail labels $TEST_ID --add "•/FYI"

Environment

• @smcllns/gmail v0.9.1
• macOS, zsh