fix: windows bug bash fixes for the node bundle, spawns, conhost glyphs, and the create wizard

[tejaskash]

Fixes the CLI issues from the 2026-09-03 Windows bug bash. Write-ups and verification are in the workspace tracker under .scratch/windows-bugbash/.

• Node bundle: no more Bun.* in production code, so the config-file region, local eval datasets, and eval online create work under Node. An oxlint rule guards it.
• Windows spawns: shell: true is gone. .cmd wrappers go through cmd.exe with quoted arguments, real executables spawn directly. Fixes the DEP0190 warning and the broken OTEL lookup.
• Python dev agents get PYTHONUTF8 and PYTHONUNBUFFERED, so emoji no longer kill the stream.
• Messages: no cd X && ... hints, no internal retry command, ctrl+c spelling, unknown subcommands named instead of "too many arguments", project remove ends its line and honours --json.
• TUI: ASCII glyph fallback for terminals without Unicode fonts, create wizard keeps its input after a failed create (esc goes back, r retries when nothing was written yet).
• Long paths: project create refuses a Windows destination that would push node_modules past MAX_PATH unless --skip-install is passed.
• README gains a "Windows notes" section.

Behavior changes worth a changelog line:

• Bun.hash became sha256, so online-eval policy and long role names change. Roles created by earlier binaries are still recognised as managed (truncated names match on their prefix) and get refreshed on a data-source move; the superseded policy written under the legacy name cannot be derived, so it stays attached and the existing stale-scope warning now says so. Fixtures were rekeyed.
• A failed create in the TUI wizard no longer exits the process nonzero; the wizard stays open.
• project remove prints its message on stderr, stdout carries only the --json object.

Verified on a Windows Server 2022 box under Node 24 (scripted over SSH plus the TUI over a pseudo-terminal). Issue 11 (paths with spaces) is in the L3 repo and needs its own PR.

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[codecov-commenter]

Codecov Report

❌ Patch coverage is 96.50146% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 97.11%. Comparing base (97d3d9a) to head (4c73624).

Files with missing lines	Patch %	Lines
src/components/EndpointWizard.tsx	55.55%	4 Missing ⚠️
src/core/onlineEvalExecutionRole.tsx	78.94%	4 Missing ⚠️
src/components/ui/_core.ts	98.24%	1 Missing ⚠️
...components/ui/status-indicator/StatusIndicator.tsx	50.00%	1 Missing ⚠️
src/core/project/backends/cdk/toolkit.ts	0.00%	1 Missing ⚠️
src/io/exec.ts	97.91%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           refactor    #2208      +/-   ##
============================================
+ Coverage     97.07%   97.11%   +0.03%     
============================================
  Files           544      546       +2     
  Lines         37866    38029     +163     
============================================
+ Hits          36760    36932     +172     
+ Misses         1106     1097       -9     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[aidandaly24]

Left three inline comments. Also, this is showing as conflicting with the current refactor tip on src/components/EndpointWizard.tsx (#2211 touched it after ErrorPanel moved out), so it will need a rebase before merge.

[aidandaly24]

I think the wizard has no way past this refusal. The message ends with "or pass --skip-install and install the CDK dependencies yourself", but the wizard hardcodes skipInstall: false (lines 188 and 204) and never asks about it, so a Windows user in a deep directory only gets a dead end and ctrl+c. I reproduced the exact text at a 187 character destination. Could the wizard either offer install as a step, or raise a wizard-specific message that just asks for a shorter directory?

[tejaskash]

Fixed in aeb1431. The way out is now caller-supplied: the CLI message mentions --skip-install, the wizard's message only asks for a shorter directory. The refusal happens before anything is written, so the wizard offers r to retry after moving directories. Added a screen-level test that drives the wizard with platform win32 and a deep cwd and checks the message, the retry hint, and that the directory stays empty.

[aidandaly24]

I may be missing a reason to keep this at module scope, but it decides the Windows branch from process.platform right after withPlatform was added so handlers would stop doing that. The cost is coverage: core.test.ts covers the predicate, but with glyphs frozen at import no component test can render the ASCII fallback across 27 call sites, and renderScreen pins process.platform too, so the wizard's new win32 refusal has no screen-level test. Would it make sense to resolve glyphs from the context, or at least let renderScreen accept a platform the way createRootHandler now does?

[tejaskash]

renderScreen now takes a platform option (aeb1431), and the wizard's win32 refusal has a screen-level test through it. I kept glyphs at module scope deliberately: it is a capability of the process's terminal rather than a per-command decision, it sits next to darkTheme, which is also a module constant every component takes as a default prop, and resolving it from the context means threading a prop through 27 leaf components for a fallback that only matters on legacy conhost. core.test.ts covers the predicate on every branch. If a second env-dependent rendering decision appears I would move both onto the theme object at that point. Happy to do it now if you feel strongly.

[aidandaly24]

I think this changes resource identity for configs created by released binaries, and the worse case fails silently rather than loudly. The prefix is 20 characters, so any config name over 44 gets a hashed role name, and for my-production-online-evaluation-config-for-the-support-assistant the suffix moves from 20487c61 to 63113c5d. eval.tsx:1232 decides a role is CLI-managed with roleArn.endsWith(onlineEvalExecutionRoleName(configName)), so after an upgrade that check fails, refreshManagedRole goes false, and a data-source move quietly stops granting the new log group instead of erroring. Shorter names keep their role but move scopePolicyName (ff687d46 to 0a7a30a7), and revokeOnlineEvalScope swallows NoSuchEntity, so the superseded policy stays attached with no warning. Since the goal here is Node compatibility rather than a naming change, would it make sense to fall back to the legacy name before treating the role as unmanaged?

[tejaskash]

Done in aeb1431. isManagedOnlineEvalRole matches a truncated role on its prefix (AgentCoreOnlineEval--), so a role with a legacy hash suffix is still treated as managed, and grantOnlineEvalScope takes the role name from the config's ARN so the refresh lands on the existing role instead of creating a second one. The superseded policy written under the legacy name cannot be derived, so revokeOnlineEvalScope now returns false on NoSuchEntity and the update path surfaces the existing stale-scope warning instead of staying silent. Unit tests cover detection for short names, truncated names with the current suffix, and truncated names with a legacy suffix.

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[notgitika]

LGTM