@loonglab/loongcode-cli 0.1.0 → 0.1.2

package/CHANGELOG.md

@@ -77,6 +77,105 @@ All notable changes to LoongCode will be documented in this file.
   capabilities now live inside the `/session` manager; they are not retained
   as aliases.
 
+## [0.1.2] - 2026-10-12
+
+A cross-platform compatibility release. Windows gets a real choice of shell —
+Windows PowerShell by default, CMD on request — and the tool layer no longer
+assumes a POSIX userland underneath: file search runs in-process instead of
+shelling out to `grep`, command output is decoded by contract rather than
+assumed to be UTF-8, cancelling a command always returns, and `@file`
+references work with spaces and Windows paths.
+
+Verification remains Linux: the automated suite runs there, the Windows paths
+are covered by simulated tests, and native Windows and macOS runs are still
+outstanding.
+
+### Added
+
+- **Windows shell selection.** `settings.shell` chooses which shell commands
+  run in on Windows: `"powershell"` (Windows PowerShell, the default) or
+  `"cmd"` (CMD, taken from `%ComSpec%`). It is global with a per-project
+  override, and an explicit choice is never replaced by the default. It applies
+  to Windows only — other platforms always run commands in `/bin/sh`, with the
+  prompts and tool descriptions they have always had. Nothing switches shells
+  automatically: if the selected shell cannot start, the command fails with an
+  error naming it instead of running somewhere else, and PowerShell 7 (`pwsh`)
+  is never chosen for you. CMD and PowerShell are different languages, so the
+  system prompt and the tool description state which one is active.
+
+### Changed
+
+- **Windows PowerShell is the default shell on Windows.** An installation that
+  never set `settings.shell` now runs commands in `powershell.exe` instead of
+  CMD; one that already chose `"cmd"` — globally or per project — keeps CMD.
+  The change is Windows only.
+- **File search no longer needs an external `grep` binary.** The `grep` tool
+  searches in-process, so it works where no `grep` exists — on Windows it
+  previously failed with "Executable not found in $PATH", which the agent read
+  as "no results". The interface, the output format (matching lines with
+  `file:line` prefixes, the 100-match cap, `No matches found.`) and the search
+  scope (`.git` and `node_modules` are still searched) are unchanged. Regular
+  expressions are JavaScript's rather than POSIX ERE: `\d`, lookahead and
+  non-greedy quantifiers now work, while `[[:alpha:]]`, `\<` and `\>` are
+  rejected with an error naming the replacement instead of silently matching
+  something else. This is not full GNU grep compatibility — the dialect, the
+  `include` glob (now the same dialect as `find`, where `{a,b}` alternates) and
+  the handling of unreadable paths all differ as described here.
+- **A search that cannot read part of the tree says so, and still returns what
+  it found.** Previously a single unreadable path failed the whole search and
+  discarded the matches; the result now carries them with a "(Search
+  incomplete: …)" note. Special files such as FIFOs and devices are skipped
+  rather than read, which removes a way for a search to block indefinitely.
+- **Subprocess output is decoded as UTF-8 unless the whole stream proves
+  otherwise.** On Windows, output that is not valid UTF-8 — `cmd.exe`
+  built-ins and many native tools write the console code page — is decoded
+  with the console code page and the result says which one was used, instead
+  of arriving as mojibake. That fallback is a labelled best guess, not
+  detection of what a program intended: the console code page describes the
+  console, not the program, and a stream can be valid UTF-8 while having been
+  written in another encoding. When no code page can be determined, the output
+  says that instead of pretending. POSIX decoding is unchanged.
+
+### Fixed
+
+- **Cancelling a command always returns.** Aborting a run (Esc) settles the
+  tool call within a bounded grace period even when the command refuses to
+  die; previously a Windows cancellation whose `taskkill` was missing or failed
+  could leave the call waiting forever, with no error and no diagnostic.
+  Termination is still best-effort — a process or descendant that escapes the
+  process tree can survive — and the result says explicitly when cleanup could
+  not be confirmed, rather than implying the tree is gone.
+- **`@file` references now work with spaces and Windows paths.** `@"my
+  notes.md"` and `@C:\src\a.ts` (either slash) expand to the file's content
+  like any other reference; they used to be left as literal text. Unresolved
+  references still stay literal, so `@` in ordinary prose is never mangled.
+
+## [0.1.1] - 2026-10-12
+
+Fixes Backspace in the terminal environments where the key arrives as a raw
+`0x08` byte. It was decoded as Ctrl+Backspace whenever `WT_SESSION` was set —
+an inherited environment variable, not a property of the byte stream — and no
+binding wanted that key, so the editor discarded the byte and nothing was
+deleted. A raw `0x08` now means plain Backspace everywhere; Ctrl+Backspace
+remains distinguishable wherever the terminal encodes it explicitly.
+
+### Fixed
+
+- Backspace deletes the character before the cursor when the terminal sends
+  `0x08` (Windows consoles, mintty/Git Bash, multiplexers, terminals started
+  from a Windows Terminal shell), not only when it sends `0x7F`.
+- Ctrl+Backspace is bound to delete-word-backward for terminals that encode it
+  unambiguously (Kitty CSI-u, modifyOtherKeys). It previously matched nothing
+  at all, on every terminal.
+
+### Added
+
+- Regression coverage for Backspace across terminal environments
+  (`packages/cli/src/interactive/input/backspace.test.ts`): the `0x08`/`0x7F`
+  matrix with `WT_SESSION` and the SSH variables present and absent, empty
+  input, deletion before the cursor, start-of-line merging, and both
+  Alt+Backspace encodings.
+
 ## [0.1.0] - 2026-09-27
 
 First working MiniCode coding-agent baseline: point the terminal UI at a

package/README.md

@@ -11,6 +11,10 @@ in an interactive terminal UI.
 LoongCode is a single platform-independent package: the same install works on
 Windows, macOS, and Linux, on both x64 and arm64.
 
+Cross-platform compatibility improvements are implemented and automated
+verification has been performed on Linux; native Windows and macOS verification
+remains pending.
+
 ```sh
 npm install -g @loonglab/loongcode-cli
 cd my-project
@@ -44,4 +48,30 @@ Configuration and sessions live under your user config directory
 (`~/.loongcode/`) — never inside
 this package.
 
+## Windows shell
+
+On Windows, commands run in Windows PowerShell (`powershell.exe`) by default.
+To run them in CMD instead, add `shell` to `settings.json`:
+
+```json
+{
+  "shell": "cmd"
+}
+```
+
+- `"powershell"` (default) — `powershell.exe`, started with `-NoLogo
+  -NoProfile -NonInteractive`; `"cmd"` — `cmd.exe`, taken from `%ComSpec%`.
+- Global (`~/.loongcode/settings.json`) with a per-project override
+  (`.loongcode/settings.json`); the project value applies, so an explicit
+  choice is never replaced by the default.
+- Windows only: other platforms always run commands in `/bin/sh`.
+- CMD and PowerShell are different languages — their syntax, built-ins and
+  scripts are not interchangeable, and neither has POSIX commands (`ls`, `cat`,
+  `grep`, …).
+- Nothing switches shells automatically: if the selected shell is unavailable
+  the command fails with an error naming it, including when PowerShell is the
+  default. `pwsh` (PowerShell 7) is not selected for you.
+- Choose `cmd` for CMD syntax, batch built-ins, or tooling that expects
+  `%ComSpec%`.
+
 See the repository README for the full product documentation.