PR #12249 was reverted (open PR #12435) because its test imported three
modules that v1.17.4 compat (2855ebbe48) removed/moved:
- Reference/RepositoryCache from ../../src/reference/* (now packages/core)
- Ripgrep from @opencode-ai/core/filesystem/ripgrep
Re-land the production fix by pointing RepositoryCache and Ripgrep at
@opencode-ai/core/{repository-cache,ripgrep} and dropping the now-gone
Reference.defaultLayer from the layer stack, matching the current
full-stack sibling (session-prompt-compaction-safety.test.ts).
Typecheck passes; all 3 watchdog tests pass.
- Drop test-only component() seams on SettingsPathDialog and
InstructionEditDialog; test layout helpers and public dialog API directly
- Remove unused settings.rules.files.remove bundle key across all locales
- Note cloud session history import fix in the changeset
The plugin runs the CLI release pinned in package.json (was 7.4.11), which contains the pre-fix cloud-import path that returns HTTP 400 BadRequest in compiled builds. The fix (#12329) first ships in CLI v7.4.13. No stable release contains it yet (7.4.14 is a draft with no assets), so pin to the v7.4.13 pre-release; the automated jetbrains-cli-pin-bump PR will move to a stable release >= 7.4.13 later. kilo.cli.pinned stays true.
Adds a Rules page under Agent Behavior for managing additional instruction files (config `instructions`) with a Skills-style list: open in editor, in-dialog content editor, and delete. Unifies the add/edit path dialog into a shared SettingsPathDialog (OK button, focused input) and hides in-place list action buttons when the list is not focused.
* fix(cli): prevent stalled agent streams
* docs(cli): clarify stream timeout scope
* test(cli): stabilize global skill permission timing
* fix(cli): make stream timeout tool-aware
* fix(cli): let the idle watchdog cancel a stalled pull immediately
An async generator's return() cannot preempt an in-flight internal
await; when suspended mid-await it only applies once that await
settles on its own. For a genuinely stalled stream that await never
settles, so interrupting a session mid-stream (e.g. aborting while a
local tool call is pending) hung instead of cancelling.
Replace the generator with a hand-rolled AsyncIterator whose return()
runs immediately and forwards to the source's return() without
waiting on any outstanding pull, matching how interruption already
behaves for the unwrapped upstream iterator.
Fixes CI failures in test/session/processor-effect.test.ts and
test/session/prompt.test.ts that hung/timed out on this branch.
* test(cli): give Windows more time for the watchdog integration bash gate
git-bash on Windows CI runners spawns and writes the readiness marker
file noticeably slower than the Unix shells this suite otherwise
runs under, so tests A and C's 5s file-poll and 30s scenario timeout
were too tight there and failed with 'readiness marker never
appeared' even though the tool was already running. Double both on
win32, matching the existing platform-aware timeout doubling in
test/kilocode/background-process.test.ts.
* test(cli): use POSIX-style paths in the watchdog bash gate script
path.join() yields backslash-separated paths on Windows. Embedded
inside a double-quoted git-bash string, a literal backslash is an
escape character, so the ready/release marker paths could resolve to
the wrong file (or nothing) instead of erroring, making 'touch' and
the '[ -f ... ]' poll silently miss each other. Normalize to forward
slashes before interpolating into the script; git-bash/MSYS accept
them natively on every platform this suite runs on.
This is the actual root cause of the 'readiness marker never
appeared' failures on Windows shards; the previous commit's timeout
doubling was only masking symptoms.
* test(cli): extend Windows margins further for the watchdog bash gate
The production bash tool runs every command through a login shell
(bash -l -c ..., src/shell/shell.ts) so ~/.bashrc/aliases behave like
an interactive terminal. Git for Windows' login-shell startup rescans
the full Windows PATH and is known to take several seconds on CI
hardware, well past the previous 15s/60s Windows margins, before the
script's own touch ever runs. Extend waitForFile to 30s and the two
affected scenario timeouts to 90s on win32.
* test(cli): give the watchdog bash gate an explicit shell so it runs on Windows
Root cause, finally isolated: without a config-level shell field, the
bash tool defaultShell() falls back to cmd.exe on Windows (see
packages/core/src/tool/bash.ts). cmd.exe cannot run bashGate POSIX
syntax (touch, test -f, while/done), so touch failed instantly and
silently and the readiness marker never appeared - no timeout was
ever going to fix that, which is why the previous two commits margin
increases did not help. Set shell to bash in tests A and C config so
the bash tool resolves real git-bash via src/shell/shell.ts on
Windows, and drop the speculative timeout inflation back to the
original values plus a small, now-accurate margin for git-bash slower
login-shell startup.
kilo-maintainer[bot]