Repository navigation
The Python branch-creation port accepts an oversized --number and crashes at int() instead of rejecting it #5194
Description
The Python branch-creation port accepts an oversized --number and crashes at int() instead of rejecting it
Project: github/spec-kit
Affected snapshot: 1c799bda6c136fcf42fb3475a922ccaac57e6c71
Summary
create_new_feature_branch.py validates --number only with the regular expression [0-9]+. A digit string longer than Python's integer-string conversion limit passes that check, but int(branch_number) later raises ValueError before any branch is created. The CLI reports an uncaught traceback instead of rejecting the value as out of domain.
Expected behavior
--number should be a bounded non-negative integer. An out-of-range value should produce the existing argument error (for example Error: --number must be a non-negative integer) and exit cleanly before branch construction.
Actual behavior
The regex accepts the 5,000-digit string. At feature_num = f"{int(branch_number):03d}", Python raises:
ValueError: Exceeds the limit (4300 digits) for integer string conversion
The command aborts with a traceback before git checkout.
Root cause
extensions/git/scripts/python/create_new_feature_branch.py:
- lines 107-116:
--numberis checked only byre.fullmatch(r"[0-9]+", args.branch_number). - line 532:
feature_num = f"{int(branch_number):03d}".
A digit string is not a bounded integer. The parser accepts values that the runtime cannot convert, and the conversion is not guarded.
Impact
- A normal CLI invocation with a malformed but syntactically numeric
--numbercrashes with an uncaught traceback instead of a user-facing error. - The feature-branch command aborts before creating or checking out the branch, leaving the caller with a partial/opaque failure.
- Automated callers that pre-validate
--numberwith the documented "non-negative integer" rule can still crash the tool.
Suggested fix
Bound the accepted value before conversion, for example:
if not re.fullmatch(r"[0-9]{1,9}", args.branch_number):
_err("Error: --number must be a non-negative integer")
raise SystemExit(1)or keep the regex and wrap the conversion:
try:
feature_num = f"{int(branch_number):03d}"
except ValueError:
_err("Error: --number is outside the supported range")
raise SystemExit(1)Define the supported maximum explicitly and test both the maximum and a value above it.
Activity
github-actions commentedon Oct 30, 2026
Bug assessment — oversized-number-crash: Valid · severity low
Bug Assessment: Oversized
--numbercrashes Python branch creation--numberand crashes atint()instead of rejecting it #5194Report (summarized)
Issue author @soarkit reports that
extensions/git/scripts/python/create_new_feature_branch.pyaccepts very large digit-only--numbervalues, then crashes when converting toint(). Expected behavior is a clean argument error; actual behavior is a traceback withValueError: Exceeds the limit (4300 digits) for integer string conversion.No additional issue comments were present at assessment time.
Symptom
When
--numberis a very long numeric string (e.g., 5000 digits), argument parsing accepts it as "non-negative integer", but branch-number formatting later raises an uncaughtValueErrorand aborts execution. Expected behavior is deterministic validation failure with a user-facing CLI error and exit code 1, without traceback.Reproduction
create_new_feature_branch.pywith--numberset to a digit-only value above Python’s integer string conversion limit (e.g.,'9' * 5000) and a valid description.[0-9]+), then execution reachesint(branch_number)and fails.[NEEDS CLARIFICATION: reporter environment details (exact Python runtime/version and invocation wrapper) were not included beyond the error text.]
Suspected Code Paths
extensions/git/scripts/python/create_new_feature_branch.py:113-115—--numbervalidation only checks regexr"[0-9]+", which enforces character class but not numeric bounds.extensions/git/scripts/python/create_new_feature_branch.py:532—feature_num = f"{int(branch_number):03d}"performs unguarded conversion and can raiseValueErrorfor oversized numeric strings.tests/extensions/git/test_git_extension.py:657-667— negative-number rejection is covered, but this does not exercise oversized positive numeric strings.tests/extensions/git/test_git_extension_python_parity.py:297-300— explicit-number happy path (42) exists; no oversized-number regression case observed.Root Cause Hypothesis
The Python extension script conflates “all characters are digits” with “value is safely representable and within accepted domain.” The parse-time validator permits arbitrarily long decimal strings, but the later conversion assumes convertibility. Python enforces a maximum digit length for integer conversion and raises
ValueErrorwhen exceeded; because this path is not caught and mapped to a user error, the CLI emits traceback-style failure. Confidence: high.Proposed Remediation
Preferred: Add explicit bounded integer validation for
--numberbefore branch formatting, mirroring the corescripts/python/create_new_feature.pypattern (_MAX_FEATURE_NUMBER = 2**63 - 1and length/lexical bound check). Then convert only after validation succeeds. Keep error messaging consistent and user-facing (no traceback).Concretely, in the extension Python script: (a) validate digits, (b) enforce max supported value, (c) return/exit with clear
Error: --number must be between 0 and <max>, got '<value>'when out of range, and (d) optionally keep a narrow defensivetry/except ValueErroraround conversion as a final guard.Alternatives (optional):
ValueErroronly at conversion site and emit an out-of-range error. Trade-off: works for this crash, but leaves domain rules implicit and less testable than a dedicated validator.Files likely to change:
extensions/git/scripts/python/create_new_feature_branch.pytests/extensions/git/test_git_extension.pytests/extensions/git/test_git_extension_python_parity.pyTests to add or update:
--numberand assert clean error (no traceback) + nonzero exit.--numberbehavior, or explicitly codify intended divergence if not shared.Risks & Considerations
Open Questions
2**63 - 1vs extension-specific bound)?]Fix oversized-number-crash: bound Python --number parsing
github-actions commentedon Oct 30, 2026
Pull request created: #5200
github-actions commentedon Oct 30, 2026
Draft PR proposed for oversized-number-crash from branch
fix/5194-oversized-number-crash: https://github.com/github/spec-kit/pulls?q=is:pr+head:fix%2F5194-oversized-number-crashSummary: the Python extension now bounds
--numberto0..2**63-1before conversion, so oversized digit-only inputs fail with a clean validation error instead of crashing atint().Next step: please review the draft PR; then run the stage-3 bug-test workflow to validate the fix if that stage is configured in this repository.
github-actions commentedon Nov 2, 2026
Bug test — oversized-number-crash: ✅ passing · 3 passed, 0 failed, 0 skipped · fix from linked pull request #5200
Bug Test Report: Oversized
--numbercrashes Python branch creation--numberand crashes atint()instead of rejecting it #51948bcee1b41219e153a3173fa9a7a027476400acce)timeout 600 python3 -m pytest -q tests/extensions/git/test_git_extension_python_parity.py::TestCreateFeatureBranchParity::test_explicit_number_max_int64_accepted tests/extensions/git/test_git_extension_python_parity.py::TestCreateFeatureBranchParity::test_explicit_number_above_max_int64_rejected tests/extensions/git/test_git_extension_python_parity.py::TestCreateFeatureBranchParity::test_explicit_number_oversized_digits_rejected_without_tracebackSummary
The fix from PR #5200 passed all relevant targeted regression and boundary tests for oversized
--numberhandling in the Python extension path. The selected tests confirm clean validation/error behavior (no traceback) and proper boundary acceptance at2**63 - 1.Test Results
Failures (if any)
None.
Verification vs. Historical Fix
not applicable (no historical fix referenced)
Notes & Caveats
closed_by_pull_requests) and tested PR [bug-fix] Fix oversized-number-crash: bound Python --number parsing #5200 head.[bug-fix] Fix oversized-number-crash: bound Python --number parsing (#…