Fix CLI init and optimize flow regressions

[mashraf-222]

Linked issue or discussion

Required: Fixes #1039

What changed

This PR fixes a set of CLI regressions across init, init-actions, --show-config, and direct optimize entry points on Windows.

The main changes are:

• make the top-level -y/--yes flag actually drive non-interactive init and init-actions flows
• stop telemetry/auth lookups from aborting local init
• fix zero-config --show-config output for Java and Go
• fix codeflash optimize --help
• harden Windows console output and optimizer startup
• fix JS/TS command execution on Windows
• fix missing-remote handling for --no-pr
• add Go GitHub Actions workflow support
• make GitHub App installation optional during plain init
• fix the Windows Python codeflash -y init regression so existing valid pyproject.toml configs are reused and CRLF files are not corrupted

Manual coverage was done in local sandboxes under manual-cli-testing/ for Python, JavaScript, TypeScript, Java, and Go.

Bugs fixed

1. Telemetry and auth lookups could abort init

• Before fix: codeflash -y init could exit before the local setup flow started when telemetry or auth lookups failed.
• Root cause and fix: event logging called user/auth lookups in paths that could raise or exit the CLI. This PR makes those failures non-fatal during local setup.
• Verified after fix: local init flows continue, and invalid API keys only fail later when a backend call is actually needed.
• Reviewer verification: set CODEFLASH_API_KEY to an invalid value and run uv run codeflash -y init in a sample repo. It should not exit during telemetry setup.

2. -y/--yes did not make init and init-actions fully non-interactive

• Before fix: codeflash -y init still hit prompts in multiple language-specific flows.
• Root cause and fix: the top-level yes flag was not threaded through the full init path, GitHub Actions setup, and the API-key prompt logic.
• Verified after fix: codeflash -y init completed without prompts in Python, JavaScript, TypeScript, Java, and Go sandboxes. codeflash -y init-actions also ran non-interactively.
• Reviewer verification: in throwaway repos for each supported language, run uv run codeflash -y init and uv run codeflash -y init-actions.

Note: this PR does not change argparse placement. The supported non-interactive form is still codeflash -y init-actions, not codeflash init-actions -y.

3. --show-config reported the wrong source and Python-oriented defaults for zero-config Java and Go projects

• Before fix: uv run codeflash --show-config in zero-config Java and Go projects could show Python-style defaults and present the config as if it came from a saved file.
• Root cause and fix: the zero-config builders returned the wrong defaults for non-Python projects, and the CLI display did not distinguish saved config from auto-detected config.
• Verified after fix: Java and Go now show language-appropriate auto-detected values, and the CLI clearly labels the config source as auto-detected.
• Reviewer verification: in a Java repo and a Go repo with no Codeflash config file, run uv run codeflash --show-config and confirm the source is shown as auto-detected and the displayed values match the language.

4. codeflash optimize --help could route into runtime logic instead of only printing help

• Before fix: uv run codeflash optimize --help did not always stop at help output.
• Root cause and fix: help handling happened too late, after language detection and optimize routing. This PR adds an early help exit path.
• Verified after fix: uv run codeflash optimize --help prints help and exits cleanly.
• Reviewer verification: run uv run codeflash optimize --help from the repo root and from a JavaScript or Java sample project. It should only print help text.

5. Windows console output could crash on Unicode rendering

• Before fix: on a Windows console with a non-UTF-8 encoding, Rich output that included Unicode box-drawing characters or emoji could raise encoding errors and abort the CLI.
• Root cause and fix: console writes assumed the active terminal encoding could represent the output. This PR adds stdio reconfigure fallbacks, plus ASCII-safe rule/title handling when needed.
• Verified after fix: CLI help and init output render in the local Windows environment without crashing on Unicode output.
• Reviewer verification: use a Windows terminal with a non-UTF-8 encoding and run uv run codeflash --help or uv run codeflash -y init.

6. Windows optimizer startup crashed when unsupported POSIX signals were registered

• Before fix: optimization on Windows could fail before reaching the backend because SIGHUP, SIGQUIT, or SIGPIPE are not supported there.
• Root cause and fix: the optimizer installed and restored POSIX signal handlers unconditionally. This PR registers only supported signals and restores only those handlers.
• Verified after fix: optimize commands no longer fail immediately with signal-related exceptions on Windows.
• Reviewer verification: on Windows, run an optimize command such as uv run codeflash --file <file> --function <name> --no-pr -y -v.

7. --no-pr optimization could crash in repos without an origin remote

• Before fix: local sandboxes without a Git remote could fail during previous-optimization lookup even when running with --no-pr.
• Root cause and fix: repository owner/name resolution still happened unconditionally in the previous-optimization lookup path. This PR skips that lookup when repo metadata is unavailable.
• Verified after fix: optimize commands in no-remote sandboxes proceed past the history lookup and continue into normal optimization flow.
• Reviewer verification: create a local git repo with no remote and run uv run codeflash --file <file> --function <name> --no-pr -y.

8. Missing Go parser support could break unrelated CLI commands

• Before fix: GoSupport eagerly instantiated the Go analyzer, so a missing tree_sitter_go dependency could break CLI startup even when the user was not running a Go command.
• Root cause and fix: Go analyzer construction happened during support initialization instead of on first use. This PR makes analyzer creation lazy and defers the error to actual Go usage.
• Verified after fix: non-Go CLI commands no longer depend on Go parser availability.
• Reviewer verification: run the Go lazy-init tests or temporarily remove the Go parser dependency and confirm non-Go CLI commands still start.

9. Windows JavaScript and TypeScript flows failed to resolve npm and npx wrappers correctly

• Before fix: JS/TS init, dependency checks, formatting, tracing, and test runners could fail on Windows because subprocess calls used bare command names instead of the actual .cmd wrappers.
• Root cause and fix: Windows Node commands are commonly exposed through wrapper executables such as npm.cmd and npx.cmd. This PR adds a resolver and uses it across the JS/TS flows.
• Verified after fix: codeflash -y init and direct optimize-entry commands in the JavaScript and TypeScript sandboxes now reach normal local execution instead of failing on command lookup.
• Reviewer verification: on Windows, run uv run codeflash -y init and a direct optimize command in a JavaScript or TypeScript project.

10. Go projects were not supported by GitHub Actions workflow generation

• Before fix: workflow detection/customization handled Python, JavaScript, TypeScript, and Java, but not Go.
• Root cause and fix: the workflow generator had no Go detection or Go customization path. This PR adds Go detection plus Go-specific workflow setup.
• Verified after fix: Go init and init-actions can now generate a Go-specific workflow.
• Reviewer verification: in a repo with go.mod, run uv run codeflash -y init-actions and confirm the generated workflow sets up Go.

11. Plain init did not let the user skip GitHub App installation

• Before fix: plain codeflash init always entered the GitHub App installation flow when an origin remote was present, even if the user wanted to continue without PR support.
• Root cause and fix: install_github_app() immediately prompted for installation instead of first asking whether the user wanted to skip it. This PR makes the GitHub App optional during plain init.
• Verified after fix: in a Python repo with origin set and no GitHub App installed, answering n to the GitHub App prompt skips the install flow and init still completes.
• Reviewer verification: in a repo with origin set but no Codeflash GitHub App installed, run uv run codeflash init and answer n when asked to install the app.

12. Windows Python codeflash -y init could rewrite valid config and corrupt CRLF pyproject.toml

• Before fix: in a Python repo that already had a valid [tool.codeflash] section, codeflash -y init always rewrote pyproject.toml. On Windows CRLF files, that could introduce \r\r\n and then fail when the file was parsed again.
• Root cause and fix: the Python skip_confirm path bypassed the existing valid-config check and always called the auto-writer, and the TOML writer used newline-translating text mode. This PR reuses existing valid configs and writes TOML with newline-preserving file handles.
• Verified after fix:
  • in a fresh clone of D:\code\optimize-me, codeflash -y init exits 0, leaves pyproject.toml byte-for-byte unchanged, and creates the local workflow
  • in a Python sandbox with a CRLF pyproject.toml and no Codeflash config, codeflash -y init writes [tool.codeflash] successfully without producing \r\r\n
• Reviewer verification: on Windows, run uv run codeflash -y init in a Python repo with an existing valid config and in one with a CRLF pyproject.toml but no Codeflash config.

Test plan

Automated verification:

• targeted regression suite on this branch: 248 passed, 12 skipped
• optimize-me baseline: 41 passed
• follow-up tests for optional GitHub App during init:
  • uv run pytest -q tests/test_init_auth.py tests/test_init_yes.py tests/test_init_java_go.py tests/test_init_javascript.py tests/test_github_workflow.py
  • result: 51 passed
• follow-up tests for the Windows Python -y init regression:
  • uv run pytest -q tests/test_init_yes.py tests/test_setup/test_config.py tests/test_setup/test_e2e_setup.py tests/test_init_java_go.py tests/test_init_javascript.py
  • result: 114 passed

Manual verification:

• ran uv run codeflash --show-config in Python, Java, and Go sandboxes
• ran uv run codeflash -y init in Python, JavaScript, TypeScript, Java, and Go sandboxes
• ran plain uv run codeflash init in a Python sandbox with origin set and no GitHub App installed, and verified that answering n skips GitHub App installation and still completes setup
• ran uv run codeflash -y init-actions in Python and Go sandboxes
• ran direct optimize-entry commands in Python, JavaScript, TypeScript, Java, and Go sandboxes using the local CLI

Observed manual end states:

• Python optimize completed its local flow and exited cleanly with No optimizations found
• JavaScript and TypeScript optimize flows got past local Windows command-resolution issues and then failed later on backend/test-generation or sample-project runtime issues
• Go optimize got past CLI setup and then stopped on a baseline timeout in the sample project
• Java optimize still hits the pre-existing Windows Gradle wrapper-selection issue (gradlew vs gradlew.bat), which is outside the scope of this PR

[mashraf-222]

Reviewer CLI verification guide for this branch

This branch now includes the original PR changes plus two follow-up fixes that are already on the PR branch:

• 2d4f49a2b Make GitHub app installation optional during init
• 793b42f29 Fix Windows Python -y init regression

Recommended setup

• Use the CLI from this branch via uv run codeflash ....
• For init tests, you can use either a valid CODEFLASH_API_KEY or an intentionally invalid one. init should not abort during telemetry/auth setup.
• For optimize-path tests, use a valid CODEFLASH_API_KEY if you want the run to get as far as the backend.
• For the non-interactive workflow path, the supported form is still codeflash -y init-actions, not codeflash init-actions -y.

Commands to test

1. uv run codeflash optimize --help
   Tested languages: Python, JavaScript, TypeScript, Java
   What this branch affects:

• early optimize help routing
  Expected behavior:
• prints optimize help only
• exits cleanly
• does not start tracer/runtime logic

2. uv run codeflash --show-config
   Tested languages: Python, Java, Go
   What this branch affects:

• zero-config Java/Go display
  Expected behavior in Python:
• prints the saved config from pyproject.toml
  Expected behavior in Java/Go zero-config repos:
• prints auto-detected config instead of implying the config came from a saved file
• does not show Python defaults such as pytest
• shows language-appropriate auto-detected values

3. uv run codeflash -y init
   Tested languages: Python, JavaScript, TypeScript, Java, Go
   What this branch affects:

• non-interactive -y flow
• non-fatal telemetry/auth setup
• local workflow generation
• Python Windows config reuse / CRLF safety
  Expected behavior in all languages:
• no confirmation prompts
• no early exit from telemetry/auth checks
• if no origin remote exists, GitHub App installation is skipped and the local workflow path is used
  Expected behavior in Python repos with an existing valid [tool.codeflash] section:
• exits 0
• does not rewrite or reconfigure the existing valid config
• does not corrupt pyproject.toml
  Expected behavior in Python repos with a CRLF pyproject.toml but no Codeflash config:
• adds [tool.codeflash]
• does not produce \r\r\n
  Expected behavior in JavaScript/TypeScript repos:
• completes without Windows npm/npx command lookup failures
  Expected behavior in Go repos:
• creates a Go-specific local workflow

4. Optional negative test for telemetry/auth during init
   Command:

• PowerShell: $env:CODEFLASH_API_KEY='cf-invalid-key'; uv run codeflash -y init
  Tested languages: any local repo
  What this branch affects:
• local init should not abort because auth/telemetry lookups fail
  Expected behavior:
• local init continues
• if a failure happens, it should happen later only when a backend call is actually needed

5. uv run codeflash init
   Tested language: Python
   Repo setup for this test:

• repo has an origin remote
• Codeflash GitHub App is not installed on that repo
  What this branch affects:
• GitHub App installation is optional during plain init
  Expected behavior:
• the flow should allow the user to skip GitHub App installation
• answering n should skip the app install path
• init should still complete successfully

6. uv run codeflash -y init-actions
   Tested languages: Python, Go
   What this branch affects:

• non-interactive workflow generation
• Go workflow generation
  Expected behavior:
• Python no-remote repo: creates .github/workflows/codeflash.yaml without prompting
• Go repo: generates or detects the Go-specific workflow without prompting

7. uv run codeflash --file <file> --function <name> --no-pr -y -v
   Tested languages: Python, JavaScript, TypeScript, Go
   What this branch affects:

• missing-remote handling for --no-pr
• Windows signal safety during optimizer startup
• JS/TS Windows command resolution
  Expected behavior in Python no-remote repos:
• should get past repository metadata lookup
• should run the normal local optimize flow
  Expected behavior in JavaScript/TypeScript repos:
• should resolve npm.CMD / npx.CMD
• should start the local test runner / optimize flow instead of failing immediately on command lookup
  Expected behavior in Go repos:
• should get past CLI setup and enter the baseline/optimize flow
  Sample commands used during manual verification:
• Python: uv run codeflash -v --file src/algorithms/string.py --function find_common_tags --no-pr -y
• JavaScript: uv run codeflash -v --file fibonacci.js --function fibonacci --no-pr -y
• TypeScript: uv run codeflash -v --file fibonacci.ts --function fibonacci --no-pr -y
• Go: uv run codeflash -v --file fibonacci.go --function Fibonacci --no-pr -y

8. Windows console encoding safety
   Command:

• PowerShell: $env:PYTHONIOENCODING='cp1252'; uv run codeflash --help
  Tested languages: generic CLI / Windows shell
  What this branch affects:
• Unicode-safe CLI output on non-UTF-8 consoles
  Expected behavior:
• prints help output instead of crashing with an encoding error

Things that can still happen but are not caused by this PR's code changes

• codeflash init-actions -y is still interactive. The supported non-interactive form remains codeflash -y init-actions.
• Java/Gradle optimize on Windows still has the pre-existing wrapper-selection issue (gradlew vs gradlew.bat -> WinError 193).
• JavaScript/TypeScript optimize can still fail later on backend test-generation errors or sample-project runtime issues after local Windows command resolution succeeds.
• Go optimize can still stop later on a baseline timeout in the sample project.
• Plain codeflash init is still interactive by design. Running it with no stdin can still hit EOFError.

What I would treat as the main reviewer smoke tests

• uv run codeflash optimize --help
• uv run codeflash --show-config in Java and Go zero-config repos
• uv run codeflash -y init in Python, JS, TS, Java, and Go repos
• uv run codeflash init in a Python repo with origin set, then answer n to skip GitHub App install
• uv run codeflash -y init-actions in a Go repo
• one direct --no-pr optimize-entry command in Python and one in JavaScript or TypeScript

[mashraf-222]

I finished a Windows before/after review for the CLI behavior in this PR and uploaded the raw artifacts here:

• Gist: https://gist.github.com/mashraf-222/7631603e6642f3afbbd331f1051d163e

What is in the gist:

• PR2157-cli-review.md: the structured review report
• README.md: a short explanation of the artifact bundle
• ReviewHelpers.ps1: the PowerShell helper I used to create fresh sandboxes and capture logs
• log-manifest.txt: mapping from each flattened gist filename back to its original path under D:\code\testing-repos\logs
• *.log: the raw stdout/stderr/exit-code captures from the manual CLI runs and the targeted pytest runs

How I generated the logs:

1. Cloned both revisions locally:
   • base: d7f95a50fbfc8567419e21610cfc9767ca244cbc
   • PR: 793b42f294ca0f3073520c57766caba99ffbf7c0
2. Set up fresh language-specific fixture repos under D:\code\testing-repos\templates.
3. For each scenario, copied a fresh fixture into D:\code\testing-repos\runs\<scenario>\<base|pr> so the base and PR runs started from the same clean state.
4. Ran the CLI with this pattern:
   • uv run --project <checkout> --directory <fresh-run-dir> codeflash ...
5. Captured the exact command line, stdout, stderr, and exit code into D:\code\testing-repos\logs\....
6. Also ran the targeted regression suite from the PR checkout and the overlapping subset from the base checkout; those logs are included in the gist as well.

Environment used for the review:

• Windows 11 Pro 10.0.26200
• PowerShell 5.1.26100.7920
• Python 3.13.3
• uv 0.9.3
• Node v20.19.6
• npm/npx 10.8.2
• Go 1.26.3
• Java 17.0.12

Main behavior changes I verified from the logs:

• optimize --help
  • base reproduces the JS help-routing bug and the Java tracing/startup bug
  • PR prints optimize help correctly
• --show-config
  • base shows Python-like saved-config defaults for zero-config Java/Go
  • PR reports zero-config Java/Go correctly
• -y init
  • base still prompts or aborts in several languages
  • PR completes non-interactively, reuses valid Python config correctly, and fixes the invalid-key local-init path
• -y init-actions
  • base hangs in the non-interactive path in this harness
  • PR completes and creates the workflow, including the Go-specific workflow
• direct --no-pr optimize
  • base crashes on Windows because of signal.SIGHUP
  • PR gets past the local startup/no-remote path and reaches backend submission
• Windows output encoding
  • base optimize --help crashes under cp1252
  • PR does not

Two limits from this run:

• The plain interactive codeflash init GitHub App skip path was hard to capture from a non-TTY Windows harness, so I treated the new passing regression tests as the authoritative evidence for that piece.
• The direct optimize runs got far enough to validate the local CLI changes in this PR, but later backend calls returned Authentication failed, so those logs should be read as local startup/routing validation rather than full end-to-end optimize success.