fix(daemon): gateway fails to launch on Windows when the profile path contains CJK characters by wsyjh8 · Pull Request #107751 · openclaw/openclaw

wsyjh8 · 2026-07-14T20:31:21Z

What Problem This Solves

Fixes an issue where Windows users whose profile path contains CJK characters (e.g. C:\Users\苗振) can install OpenClaw but the gateway never starts: the first run fails with a "The system cannot find the file specified" / "找不到 …\gateway.vbs" popup and the Scheduled Task never launches the gateway. Reported against v2026.7.1 on Windows 11 with a Chinese-locale profile path.

Why This Change Was Made

The daemon writes the generated launchers (gateway.cmd, the hidden gateway.vbs introduced by #95480, and the Startup-folder fallback entry) as UTF-8 without BOM, but neither Windows script host reads that encoding: wscript.exe parses .vbs only as ANSI or UTF-16 LE with BOM, and cmd.exe parses .cmd in the console (OEM) code page. CJK path bytes inside the launchers garble and the launch chain breaks at the first hop.

This PR adds src/daemon/launcher-encoding.ts — a per-format encoder plus a BOM-sniffing decoder — used at the three launcher write sites and the readScheduledTaskCommand parse site in src/daemon/schtasks.ts:

.vbs → always UTF-16 LE with BOM, the one wscript encoding that is correct on every locale.
.cmd → ASCII content stays byte-identical UTF-8 (zero change for non-CJK installs). Non-ASCII content is encoded with the system ANSI code page, but only on locales where ANSI == OEM (936/932/949/950/874/GB18030 — the locales where a code-page fix is well-defined). windows-125x locales keep UTF-8: their console OEM page (437/850/852/866…) differs from ANSI and has no WHATWG decoder, so ANSI bytes would just be a different flavor of wrong there. Encoded output is round-trip-verified with the same decoder the read path uses; unmappable characters fail the install with a clear error instead of writing a silently broken launcher.
Read-back BOM-sniffs UTF-16, then tries strict UTF-8 first (covers ASCII and all pre-fix installs with no code page probe on the frequent poll path), then falls back to the ANSI code page — so repair/update parses legacy files fine and rewrites the state-dir launchers in the new encodings.

Design notes:

Why not UTF-16 for .cmd: cmd.exe cannot parse UTF-16 batch files (NUL bytes break the parser).
Why iconv-lite: encoding to GBK/Big5/… is required and TextDecoder only decodes. [email protected] is already in the dependency tree (express → body-parser/raw-body), so promoting it to a root dependency resolves to the already-locked version and adds no new packages — the npm-shrinkwrap.json delta is one line. If a no-new-root-dependency route is preferred, the alternative is keeping .cmd UTF-8 and prepending @chcp 65001>nul; that mutates the console code page for child processes and relies on cmd's re-read behavior, but I am happy to switch if maintainers prefer it.
Code page detection reuses the existing cached resolveWindowsSystemEncoding() in src/infra/windows-encoding.ts (now exported); no new detection code.
Known sibling surface (explicit follow-up, not in this PR): src/infra/windows-task-restart.ts writes its temp restart .cmd as UTF-8 with the same class of embedded paths, so the update-time restart path on CJK hosts needs the same treatment. Kept out to hold this PR to one concern; I can file the follow-up issue once this lands.

User Impact

Windows users with CJK (or Thai) characters anywhere in their profile/state path can now install and start the gateway, and gateway repair/update migrates existing broken installs by rewriting the state-dir launchers. Users with pure-ASCII paths get byte-identical launcher files — no change at all.

Evidence

New unit coverage src/daemon/launcher-encoding.test.ts (12 tests: UTF-16 BOM output incl. a CJK path, ASCII byte-identity under a pinned code page, GBK round-trip, windows-125x gate, unrepresentable-character failure, legacy-UTF-8 and raw-GBK decode).
Migration coverage in schtasks.test.ts: readScheduledTaskCommand parses both a legacy UTF-8 CJK script and a GBK-encoded script.
Install-path coverage in schtasks.install.test.ts: the hidden .vbs launcher for a CJK profile path starts with FF FE and utf16le-decodes to the exact Run """…""", 0, False line; an unrepresentable env value fails the install with no launcher file written.
Focused runs on Windows (Node 24.18, pnpm 11.2.2): launcher-encoding 12/12, schtasks + schtasks.install 48/48, schtasks.startup-fallback + service-env + windows-encoding 137/137; oxlint and oxfmt clean on changed files; tsgo:core and tsgo:test:src clean; deps:shrinkwrap:root:check reports current. (schtasks.stop.test.ts shows 4 failures on this host that reproduce identically on unmodified main — pre-existing and unrelated.)
Real-machine smoke test on Chinese Windows 10 (ACP=OEMCP=936, the reporter's locale family): a gateway.vbs/gateway.cmd pair written under %TEMP%\苗振\ with the new encoder launches via cscript gateway.vbs and the payload creates proof.txt; the same pair written the old way (plain UTF-8) fails with gateway-old.vbs(1, 1) (null): The system cannot find the file specified. — the exact reported symptom — and no proof file appears.

… can decode gateway.vbs and gateway.cmd were written as UTF-8 without BOM, but wscript.exe only reads .vbs as ANSI or UTF-16 LE with BOM and cmd.exe reads .cmd in the console OEM code page, so installs under CJK profile paths failed with "file not found" (openclaw#107416). Write .vbs as UTF-16 LE with BOM, write non-ASCII .cmd content in the system code page when it matches the console page (CJK/Thai locales), and BOM-sniff plus code-page-fallback on read so launchers from older installs keep parsing and migrate on refresh. The hidden .vbs launch path originates from openclaw#95480, which addressed console visibility only.

github-actions · 2026-07-14T20:31:51Z

Dependency Guard

This PR changes dependency-related files. Maintainers should confirm these changes are intentional.

Changed files:

npm-shrinkwrap.json
package.json
pnpm-lock.yaml

Maintainer follow-up:

Review whether the dependency changes are intentional.
Inspect resolved package deltas when lockfile, shrinkwrap, or workspace dependency policy changes are present.
Treat package-lock.json and npm-shrinkwrap.json diffs as security-review surfaces.
Run pnpm deps:changes:report -- --base-ref origin/main --markdown /tmp/dependency-changes.md --json /tmp/dependency-changes.json locally for detailed release-style evidence.

github-actions · 2026-07-14T20:32:07Z

Dependency graph change authorized

This PR includes dependency graph changes. A repository admin or member of @openclaw/openclaw-secops authorized this exact head SHA with /allow-dependencies-change.

Approved SHA: a399e92e0a50ac5fc25ed174118adc1969513dd9
Approved by: @steipete

A later push changes the PR head SHA and requires a fresh security approval.

The type is only referenced by encodeWindowsLauncherScript's format parameter within the module, so the export tripped check-deadcode-exports. Keep it module-local.

clawsweeper · 2026-07-15T09:36:06Z

Codex review: needs maintainer review before merge. Reviewed July 15, 2026, 7:27 PM ET / 23:27 UTC.

Summary
The PR adds format-aware encoding and decoding for Windows gateway launchers and restart helpers, updates scheduled-task read/write paths, adds regression coverage, and promotes iconv-lite to a direct root dependency.

PR surface: Source +133, Tests +389, Config +1, Other +4. Total +527 across 13 files.

Reproducibility: yes. Current main's UTF-8 launcher writes match the reported failure path, and the PR includes a real Chinese Windows comparison where the old launchers fail while the encoded launchers execute successfully.

Review metrics: 1 noteworthy metric.

Direct dependency surface: 1 added, 0 newly resolved packages. The patch promotes iconv-lite 0.7.2 from an existing transitive resolution to a direct core dependency, which requires explicit dependency authorization.

Stored data model
Persistent data-model change detected: serialized state: src/daemon/schtasks.install.test.ts, serialized state: src/daemon/schtasks.startup-fallback.test.ts, serialized state: src/daemon/schtasks.test.ts, serialized state: src/daemon/schtasks.ts. Confirm migration or upgrade compatibility proof before merge.

Root-cause cluster
Relationship: fixed_by_candidate
Canonical: #107416
Summary: This PR is the active candidate fix for the canonical CJK-profile launcher-encoding issue; an older issue and unmerged PR describe the same underlying Windows decoding failure.

Members:

canonical: gateway.vbs/gateway.cmd encoding issue on Windows with CJK username paths #107416 - The PR explicitly closes this issue and implements its requested launcher-encoding repair.
same_root_cause: [Bug]: [Windows] Gateway fails to start with Chinese username path #43943 - It reports the same Windows gateway service failure when a Chinese username appears in the generated task-script path.
superseded: fix(windows): bootstrap UTF-8 before running gateway task script #43975 - The older closed-unmerged PR attempted a narrower chcp-based repair; this PR provides the active, broader launcher and readback solution.
adjacent_distinct: fix #89231: [Bug]: Windows installer-created scheduled task launches gateway.cmd with visible console — should use windowless launcher #95480 - That merged PR introduced the hidden gateway.vbs launch path, but addressed console visibility rather than script encoding.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Merge readiness
Overall: 🐚 platinum hermit
Proof: 🦞 diamond lobster
Patch quality: 🐚 platinum hermit
Result: ready for maintainer review.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

Obtain admin or security authorization for the exact iconv-lite dependency change, then rebase and rerun the required checks.

Risk before merge

[P1] The direct iconv-lite dependency remains unauthorized for this external PR head, so the dependency guard intentionally blocks merge until repository admin or security approval is recorded.
[P1] The patch changes generated launcher bytes and makes unrepresentable code-page content fail installation or restart rather than writing a silently broken script; that compatibility and availability behavior is deliberate but should be explicitly accepted before merge.
[P1] The branch is behind current main and needs a base refresh so the reviewed encoding paths and tests are confirmed against the actual merge result.

Maintainer options:

Authorize, refresh, and merge (recommended)
Approve iconv-lite for this exact head, rebase onto current main, and require the Windows launcher and dependency checks to pass before landing.
Pause for a no-dependency redesign
If a new direct root dependency is not acceptable, pause this branch and request a different encoding approach before further merge work.

Next step before merge

[P2] The code blocker from the previous review is fixed; a human admin or security owner must now authorize the direct dependency change and confirm the refreshed merge result.

Maintainer decision needed

Question: Should this head be authorized to add iconv-lite 0.7.2 as a direct root dependency for Windows launcher encoding?
Rationale: The implementation needs a real legacy-code-page encoder, and the chosen version is already transitively resolved, but repository policy deliberately requires a human admin or security decision before an external PR may alter dependency graph fields.
Likely owner: steipete — The available history ties this person to recent Windows gateway lifecycle decisions, making them the best routing candidate for coordinating the required dependency authorization.
Options:
- Authorize iconv-lite (recommended): Approve the exact current head's direct dependency change, then rebase and rerun required checks before merge.
- Require a dependency-free design: Do not authorize the manifest change and ask for a revised launcher strategy that does not rely on adding a direct dependency.

Security
Needs attention: No malicious or vulnerable package delta is evident, but the external PR's direct dependency change requires explicit repository-admin or security authorization before merge.

Review details

Best possible solution:

Authorize the exact iconv-lite dependency change for the current head, preserve the deterministic marker-based encoder across both launcher and restart-helper paths, rebase onto current main, and rerun the Windows and dependency gates before merging.

Do we have a high-confidence way to reproduce the issue?

Yes. Current main's UTF-8 launcher writes match the reported failure path, and the PR includes a real Chinese Windows comparison where the old launchers fail while the encoded launchers execute successfully.

Is this the best way to solve the issue?

Yes. A shared per-format encoder with explicit code-page markers is narrower and safer than scattered write-site fixes, and the latest head also covers the sibling restart-helper path; only dependency authorization and merge-base refresh remain.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 1643f1fd9f4c.

Label changes

Label justifications:

P0: A first-time Windows installation under a CJK profile path cannot launch the gateway and has no non-technical in-product recovery path.
merge-risk: 🚨 compatibility: Generated .cmd and .vbs encodings change on upgrade, and unrepresentable code-page content now fails closed instead of writing the previous UTF-8 files.
merge-risk: 🚨 availability: Any launcher-encoding mistake or unsupported character can prevent the scheduled gateway or update-time restart helper from starting.
rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🦞 diamond lobster and patch quality is 🐚 platinum hermit.
status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (live_output): The PR provides after-fix live output from a Chinese Windows 10 machine showing the encoded launcher succeeds under a CJK path while the old UTF-8 launcher reproduces the reported failure.
proof: sufficient: Contributor real behavior proof is sufficient. The PR provides after-fix live output from a Chinese Windows 10 machine showing the encoded launcher succeeds under a CJK path while the old UTF-8 launcher reproduces the reported failure.

Evidence reviewed

PR surface:

Source +133, Tests +389, Config +1, Other +4. Total +527 across 13 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	5	146	13	+133
Tests	5	403	14	+389
Docs	0	0	0	0
Config	1	1	0	+1
Generated	0	0	0	0
Other	2	4	0	+4
Total	13	554	27	+527

Security concerns:

[low] Authorize the direct dependency change — package.json:2047
The patch adds iconv-lite to root dependencies and both lock surfaces; although version 0.7.2 is already transitively resolved, repository policy blocks external dependency graph changes until an admin or security owner approves this exact head.
Confidence: 0.99

What I checked:

Current-main failure path: Current main reads and writes generated Windows task scripts as UTF-8, while the hidden WScript launcher and cmd.exe consume locale-specific encodings; this matches the linked CJK-profile startup failure. (src/daemon/schtasks.ts:250, 1643f1fd9f4c)
Shared encoder applied: The branch routes scheduled-task .cmd files, hidden .vbs launchers, startup fallback entries, and the update-time restart helper through the new format-aware encoder. (src/daemon/launcher-encoding.ts, efa5cb2f977a)
Prior finding resolved: Commit b311a3c adds an ASCII encoding marker to code-page launchers so byte sequences that are also valid UTF-8 are decoded deterministically; the earlier P1 should not be re-raised. (src/daemon/launcher-encoding.ts, b311a3ccacfe)
Sibling surface covered: The latest branch also encodes the temporary Windows scheduled-task restart script, addressing the sibling path identified during the first review cycle. (src/infra/windows-task-restart.ts:90, a562060607d3)
Real Windows proof: The PR body reports a Chinese Windows 10 smoke test where the new launcher pair under a CJK path executed and created the expected proof file, while the old UTF-8 pair reproduced the reported file-not-found failure. (efa5cb2f977a)
Dependency gate remains: The branch adds iconv-lite 0.7.2 as a direct dependency. The version is already resolved transitively, but repository automation requires explicit admin or security authorization for an external PR changing dependency graph fields. (package.json:2047, efa5cb2f977a)

Likely related people:

mikasa0818: Authored the merged hidden-launcher change that made gateway.vbs the default Windows scheduled-task action, directly defining the affected launch chain. (role: introduced adjacent behavior; confidence: high; commits: f5148aff2505; files: src/daemon/schtasks.ts, src/daemon/schtasks.install.test.ts, src/daemon/service-env.ts)
steipete: Recent landed work and issue follow-up cover Windows gateway stop, restart, stale-listener cleanup, and scheduled-task lifecycle behavior adjacent to this patch. (role: recent Windows gateway contributor; confidence: medium; commits: 5ea03ef, 6cb8729, 5189ba8; files: src/daemon/schtasks.ts, src/infra/windows-task-restart.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

Review history (2 earlier review cycles)

reviewed 2026-07-15T09:31:36.699Z sha 7627f95 :: needs changes before merge. :: [P1] Disambiguate code-page launchers before trying UTF-8
reviewed 2026-07-15T22:41:08.344Z sha efa5cb2 :: needs maintainer review before merge. :: none

@Rem

…erministic readback Prepend an ASCII '@Rem openclaw-launcher-encoding=<label>' line to code-page .cmd launchers and decode by that marker instead of sniffing UTF-8. Some GBK byte sequences are valid UTF-8 (隆 = C2 A1 reads as ¡), so the old sniff silently corrupted readback and rejected valid paths; the marker makes decode deterministic and drops the code-page probe (a PowerShell spawn) from the frequent readScheduledTaskCommand poll path. Also fix the representability guard for euc-kr: Node ICU decodes euc-kr as KS X 1001 only, but Windows code page 949 is cp949/UHC, so the TextDecoder cross-check false-rejected ~8,800 UHC extension syllables (똠 = 8C 63) that iconv encodes and cmd.exe reads fine. Verify euc-kr via iconv's own cp949 round-trip; keep TextDecoder for the other five labels.

… encoder The update-time restart helper wrote its temp .cmd as raw UTF-8 while embedding the restart-log path, task name, and task script path, so a CJK profile path or task name broke the same way as the gateway launchers (openclaw#107416). Route the write through encodeWindowsLauncherScript: ASCII content stays byte-identical UTF-8, CJK content gets the marked code-page encoding, and an unrepresentable task name now fails the restart attempt cleanly instead of writing a script cmd.exe would misread.

Reset pnpm-lock.yaml to origin/main and re-add only the iconv-lite root importer entry, dropping the unrelated @types/node peer-context flips and audio-decode deprecation metadata that a mismatched-toolchain regeneration had pulled in. The diff vs main is now the three-line importer entry only; the version already resolves in main's tree via express -> body-parser/raw-body.

steipete · 2026-07-16T06:09:00Z

/allow-dependencies-change

Co-authored-by: Jason Yao <[email protected]>

steipete · 2026-07-16T06:17:26Z

/allow-dependencies-change

steipete · 2026-07-16T06:58:19Z

/allow-dependencies-change

steipete · 2026-07-16T07:14:49Z

/allow-dependencies-change

steipete · 2026-07-16T07:21:08Z

/allow-dependencies-change

steipete · 2026-07-16T07:43:00Z

Merged via squash.

Prepared head SHA: a399e92e0a50ac5fc25ed174118adc1969513dd9
Landed commit: ccec0224fa2e3cd5f782bb9b2a83dda8d3b9f0b9

@Rem

… contains CJK characters (openclaw#107751) * fix(daemon): write Windows gateway launchers in encodings wscript/cmd can decode gateway.vbs and gateway.cmd were written as UTF-8 without BOM, but wscript.exe only reads .vbs as ANSI or UTF-16 LE with BOM and cmd.exe reads .cmd in the console OEM code page, so installs under CJK profile paths failed with "file not found" (openclaw#107416). Write .vbs as UTF-16 LE with BOM, write non-ASCII .cmd content in the system code page when it matches the console page (CJK/Thai locales), and BOM-sniff plus code-page-fallback on read so launchers from older installs keep parsing and migrate on refresh. The hidden .vbs launch path originates from openclaw#95480, which addressed console visibility only. * refactor(daemon): drop unused WindowsLauncherScriptFormat export The type is only referenced by encodeWindowsLauncherScript's format parameter within the module, so the export tripped check-deadcode-exports. Keep it module-local. * fix(daemon): mark code-page cmd launchers with their encoding for deterministic readback Prepend an ASCII '@Rem openclaw-launcher-encoding=<label>' line to code-page .cmd launchers and decode by that marker instead of sniffing UTF-8. Some GBK byte sequences are valid UTF-8 (隆 = C2 A1 reads as ¡), so the old sniff silently corrupted readback and rejected valid paths; the marker makes decode deterministic and drops the code-page probe (a PowerShell spawn) from the frequent readScheduledTaskCommand poll path. Also fix the representability guard for euc-kr: Node ICU decodes euc-kr as KS X 1001 only, but Windows code page 949 is cp949/UHC, so the TextDecoder cross-check false-rejected ~8,800 UHC extension syllables (똠 = 8C 63) that iconv encodes and cmd.exe reads fine. Verify euc-kr via iconv's own cp949 round-trip; keep TextDecoder for the other five labels. * fix(infra): write Windows restart helper scripts through the launcher encoder The update-time restart helper wrote its temp .cmd as raw UTF-8 while embedding the restart-log path, task name, and task script path, so a CJK profile path or task name broke the same way as the gateway launchers (openclaw#107416). Route the write through encodeWindowsLauncherScript: ASCII content stays byte-identical UTF-8, CJK content gets the marked code-page encoding, and an unrepresentable task name now fails the restart attempt cleanly instead of writing a script cmd.exe would misread. * chore(deps): minimize pnpm-lock delta for the iconv-lite promotion Reset pnpm-lock.yaml to origin/main and re-add only the iconv-lite root importer entry, dropping the unrelated @types/node peer-context flips and audio-decode deprecation metadata that a mismatched-toolchain regeneration had pulled in. The diff vs main is now the three-line importer entry only; the version already resolves in main's tree via express -> body-parser/raw-body. * refactor(windows): centralize launcher encoding Co-authored-by: Jason Yao <[email protected]> * style(windows): format launcher encoding test --------- Co-authored-by: Peter Steinberger <[email protected]> Co-authored-by: Peter Steinberger <[email protected]>

wsyjh8 requested a review from a team as a code owner July 14, 2026 20:31

openclaw-barnacle Bot added gateway Gateway runtime size: M labels Jul 14, 2026

github-actions Bot added the dependencies-changed PR changes dependency-related files label Jul 14, 2026

wsyjh8 mentioned this pull request Jul 14, 2026

gateway.vbs/gateway.cmd encoding issue on Windows with CJK username paths #107416

Closed

refactor(daemon): drop unused WindowsLauncherScriptFormat export

7627f95

The type is only referenced by encodeWindowsLauncherScript's format parameter within the module, so the export tripped check-deadcode-exports. Keep it module-local.

BradGroux mentioned this pull request Jul 15, 2026

WORKING: All Microsoft Issues and PRs (refresh) #74163

Draft

wsyjh8 added 3 commits July 15, 2026 18:33

openclaw-barnacle Bot added size: L and removed size: M labels Jul 15, 2026

clawsweeper Bot added rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. and removed rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. labels Jul 16, 2026

steipete self-assigned this Jul 16, 2026

refactor(windows): centralize launcher encoding

6db0aab

Co-authored-by: Jason Yao <[email protected]>

style(windows): format launcher encoding test

900cf07

Merge branch 'main' into fix/107416-launcher-encoding

94b9318

Merge branch 'main' into fix/107416-launcher-encoding

a399e92

steipete merged commit ccec022 into openclaw:main Jul 16, 2026
120 of 121 checks passed

steipete mentioned this pull request Jul 16, 2026

refactor(windows): remove launcher encoding test seam #108750

Merged

github-actions Bot mentioned this pull request Jul 16, 2026

📡 Upstream Digest — 2026-07-16 07:58 UTC curtismercier/openclaw-mods#1310

Open

Yigtwxx mentioned this pull request Jul 16, 2026

fix: gateway.cmd launcher garbles non-ASCII profile paths on non-CJK Windows locales #108967

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(daemon): gateway fails to launch on Windows when the profile path contains CJK characters#107751

fix(daemon): gateway fails to launch on Windows when the profile path contains CJK characters#107751
steipete merged 9 commits into
openclaw:mainfrom
wsyjh8:fix/107416-launcher-encoding

wsyjh8 commented Jul 14, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Jul 14, 2026

Uh oh!

github-actions Bot commented Jul 14, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jul 15, 2026 •

edited

Loading

Uh oh!

steipete commented Jul 16, 2026

Uh oh!

steipete commented Jul 16, 2026

Uh oh!

steipete commented Jul 16, 2026

Uh oh!

steipete commented Jul 16, 2026

Uh oh!

steipete commented Jul 16, 2026

Uh oh!

Uh oh!

steipete commented Jul 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

wsyjh8 commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What Problem This Solves

Why This Change Was Made

User Impact

Evidence

Uh oh!

github-actions Bot commented Jul 14, 2026

Dependency Guard

Uh oh!

github-actions Bot commented Jul 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Dependency graph change authorized

Uh oh!

clawsweeper Bot commented Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

steipete commented Jul 16, 2026

Uh oh!

steipete commented Jul 16, 2026

Uh oh!

steipete commented Jul 16, 2026

Uh oh!

steipete commented Jul 16, 2026

Uh oh!

steipete commented Jul 16, 2026

Uh oh!

Uh oh!

steipete commented Jul 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

wsyjh8 commented Jul 14, 2026 •

edited

Loading

github-actions Bot commented Jul 14, 2026 •

edited

Loading

clawsweeper Bot commented Jul 15, 2026 •

edited

Loading