Harvested from PR #1487 by @Jianfengwu2024 — the rest of that PR
(the TriadMind architecture-governance crate) needs a Discussion-
level design conversation before it can land, but this Windows
env-allowlist fix is a clean independent improvement and stands on
its own.
When the parent shell has already loaded VsDevCmd / vcvars (the
standard pattern for running Rust + MSVC on Windows), `exec_shell`
was stripping the toolchain env on its way to the child. The result:
the model finds `link.exe` via `PATH` but the linker can't resolve
`kernel32.lib` / `ucrt.lib` because LIB and the SDK roots were
filtered out. Any model-driven `cargo build` from inside the TUI
silently broke on Windows installs that don't run inside a Developer
Command Prompt.
Adds 13 MSVC-related env vars to the `is_allowed_parent_env_key`
allowlist so they survive the sanitization pass:
LIB / LIBPATH / INCLUDE
VSINSTALLDIR / VCINSTALLDIR / VCTOOLSINSTALLDIR
WINDOWSSDKDIR / WINDOWSSDKVERSION
UNIVERSALCRTSDKDIR / UCRTVERSION
EXTENSIONSDKDIR / DEVENVDIR / VISUALSTUDIOVERSION
Also extends the `mcp_env_allowlist_inherits_base_keys` fixture and
adds `sanitized_child_env_preserves_windows_toolchain_vars` as a
regression test (locked under `env_lock()` so it serialises with the
other env-mutating tests in the file).
Pure additive — no non-Windows behaviour changes.
Harvested from PR #1487 by @Jianfengwu2024
Closes the "code_execution: program not found" failure reported by a
Windows contributor and adds the surrounding plumbing so future
external-binary dependencies can be added without each one repeating
the same probe-and-skip logic.
New module `crates/tui/src/dependencies.rs`:
* `PYTHON_CANDIDATES = ["python3", "python", "py -3"]` — try the
Unix-style name first, then the bare name (common on Windows and
modern macOS), then the Windows launcher as a last resort.
* `probe_executable(spec)` — splits the spec on whitespace, spawns
`<program> [args...] --version`, returns true on success. stdout
and stderr are routed to /dev/null so the probe doesn't print to
the TUI's first frame.
* `resolve_python_interpreter()` — OnceLock-cached resolver that
returns the first candidate that probed successfully, or None.
* `resolve_pdftotext()` — same shape, for doctor's PDF-path
diagnostic.
* `split_interpreter_spec("py -3") → ("py", ["-3"])` — needed so
`tokio::process::Command::new(program).args(args).arg(script)`
runs the Windows launcher correctly.
Wiring in `core/engine/tool_catalog.rs::ensure_advanced_tooling`:
* The hardcoded `catalog.push(Tool { name: "code_execution", … })`
is now gated on `resolve_python_interpreter().is_some()`. On a
machine without Python the tool is not advertised — the model
never sees a tool it can't actually run, which removes the
"Failed to execute tool: program not found" class of failure
entirely. On a machine WITH Python the behavior is unchanged
from the user's perspective.
Wiring in `execute_code_execution_tool`:
* Resolves the interpreter at call time (still cached) and splits
on whitespace so `py -3` runs as `py -3 /tmp/.../code.py`.
* Writes the user code to a tempfile under tempdir() and runs the
file rather than passing it through `python3 -c "..."`. Fixes
argv length limits on Windows, multiline code with quote
nesting, and traceback line numbers (real filename instead of
`<string>`). Folds in the contributor's Part 2 proposal.
* Returns a clear actionable error if the interpreter somehow
disappears between startup and the call (uninstall mid-session,
PATH manipulation, etc.).
Doctor (`crates/tui/src/main.rs::run_doctor`) gains two new sections:
* "Tool Dependencies": ✓/✗ for Python and pdftotext with a
platform-specific install hint when missing. The Python miss
explicitly tells users that `code_execution` is not advertised.
* "Terminal Quirks": shows which env-driven auto-overrides are
currently active (VS Code / Ghostty low-motion, Termius/SSH
low-motion per #1433, Ptyxis sync-output-off per v0.8.31).
Answers the "why is my flicker / motion behaving this way"
question without needing the user to read the source.
The contributor's Part 1 proposal (share the sandbox/approval
substrate with task_shell_start) is deferred to v0.8.32 — that
touches `sandbox/` which CLAUDE.md flags as "stop and ask before
changing" and needs an explicit design pass on approval semantics.
Six new unit tests in `dependencies.rs` covering probe behavior,
spec splitting, and cache stability. Existing tool_catalog tests
still pass.
Solves the long-standing hygiene problem where contributor PRs whose
code lands via maintainer cherry-pick stay open + CONFLICTING forever,
even though their fix is credited in the CHANGELOG. v0.8.29 alone left
~5 such PRs open (#1421, #1429, #1442, #1465 — verified separately).
New workflow `.github/workflows/auto-close-harvested.yml`:
* Triggers on push to main.
* For each commit in the push, scans the commit body for lines
matching `harvested from (PR )?#N` (case-insensitive).
* For each matched PR number, closes the PR with a templated
thank-you that links back to the merged commit, thanks the
contributor by handle, and points them at CONTRIBUTING for
landing future PRs via the faster direct-merge path.
* Idempotent — already-closed PRs are skipped with a log line,
not an error.
* Concurrency-guarded so two near-simultaneous main pushes can't
both try to close the same PR.
Two commit-message patterns are recognised:
* `Harvested from PR #1234 by @username` (preferred form, used
in the templates the maintainer paste-uses for harvests)
* `harvested from #1234` (case-insensitive
fallback for older / shorter forms)
The convention is documented in CONTRIBUTING.md, which also adds a
new "How Your Contribution Lands" section explaining the harvest
model upfront so contributors know what to expect — closing their
PR isn't rejection, and the credit lives in the commit message and
CHANGELOG.
Permissions on the workflow: `pull-requests: write` to close + comment,
`issues: write` for the comment (PR comments are issue comments under
the hood), `contents: read` for the checkout.
Closes the persistent "fatal: could not read Username for 'https://cnb.cool'"
failure that bit about half of recent sync-cnb runs.
Root causes from the failure log of run 25705666413 (2026-05-12) and
25697452832 (2026-05-11):
1. The previous tencentcom/git-sync Docker action discovered every
local ref via fetch-depth: 0 and tried to push them all —
including dependabot/* branches that GitHub had locally. Those
follow-on pushes ran without the configured credential helper
in scope and failed with the basic-auth prompt error above.
2. No concurrency guard meant the back-to-back `main` push and
`v*` tag push that auto-tag.yml fires within ~15s of each other
raced. Two workflow runs would attempt to push to the same
CNB remote simultaneously; one would lose.
Rewrite:
* Hand-rolled `git push` with the CNB token URL-encoded inline so
the credential is always in scope. No Docker action dependency.
* `concurrency: group: cnb-sync, cancel-in-progress: false` so
queued runs serialize cleanly rather than racing or dropping.
* Only push the ref that triggered the run — `main` on branch
push (with --force-with-lease for safety), the specific tag on
tag push. Feature branches and dependabot refs no longer
mirror.
* 3-attempt retry with linear backoff (5s, 10s) for transient
failures (CNB rate-limit, DNS blips, etc.).
* `workflow_dispatch: {}` trigger so the maintainer can re-run
against a specific ref manually if the automated run fails.
Adds docs/CNB_MIRROR.md with: the verification steps after a
release, the manual fallback procedure (one-time `git remote add cnb`,
then `git push cnb vX.Y.Z`), the token-rotation procedure, and a
note on why binary release assets aren't on CNB today.
Cross-links from docs/RELEASE_RUNBOOK.md so the verify-after-release
step doesn't get forgotten.
Clears the open Dependabot alerts on `Hmbown/DeepSeek-TUI`:
* GHSA-26hh-7cqf-hhc6 (high) — Next.js App Router middleware /
proxy bypass via segment-prefetch routes; fixed in 15.5.18.
* Four mermaid CVEs (all medium) — Gantt-chart infinite-loop
DoS, `classDef` HTML injection, configuration CSS injection,
`classDefs` CSS injection; fixed in 11.15.0.
Also bumps `eslint-config-next` to 15.5.18 to track the Next.js
release. `npm run build` is clean on the regenerated lockfile.
These are web/ only — the Rust TUI binary doesn't pull in any of
this. Affects the separately-deployed deepseek-tui.com site.
Closes#1433. Harvested from PR #1479 by @CrepuscularIRIS / autoghclaw,
with two changes from the original PR:
* `is_some_and` instead of `.map_or(false, |v| !v.is_empty())` —
the latter trips `clippy::unnecessary_map_or` on Rust 1.94+
under `-D warnings`, which is what blocked the PR's Lint check
in CI. is_some_and reads cleaner and ships the same behavior.
* `non_vscode_term_program_does_not_force_low_motion` now clears
SSH_CLIENT / SSH_TTY before iterating its negative-case
fixtures so the suite still passes when run from a developer's
actual SSH session.
Detection logic mirrors the existing VS Code (#1356) and Ghostty
(#1445) overrides: any of TERM_PROGRAM=Termius, SSH_CLIENT set, or
SSH_TTY set unconditionally flips low_motion = true and
fancy_animations = false. The 120 FPS cursor-repositioning that
caused the cursor to cycle through input boxes over SSH is dropped
to the 30 FPS cap the typewriter path already uses.
Two new tests: termius_term_program_forces_low_motion_on and
ssh_session_forces_low_motion_on. Both serialise through the
existing term_program_test_guard / crate-wide test lock to avoid
racing concurrent env-var-mutating tests in the suite.
Closes#1454. Harvested from PR #1456 by @Oliver-ZPLiu.
Adds `pub headers: HashMap<String, String>` to McpServerConfig,
threaded through HttpTransport::new and StreamableHttpTransport so
every outbound POST applies the user-configured headers after the
fixed Accept / Content-Type framing. Mirrors the field shape that
Claude Code, Codex, and OpenCode already accept in their MCP
config formats — unblocks Hugging Face MCP, GitHub MCP, Atlassian
Rovo MCP, and any other Streamable HTTP gateway that needs a
Bearer token or API key.
Defense-in-depth filter (`is_safe_custom_header`) drops:
* empty / whitespace-only keys (would surface as a reqwest
builder error mid-send and abort the connection);
* `Accept` / `Content-Type` duplicates (the MCP Streamable HTTP
protocol negotiates on these exact values; a stray override
would silently break tool discovery);
* values containing ASCII CR or LF (response-splitting defense
against a misbehaving proxy).
Skipped headers emit a `tracing::warn!` and the rest of the
request still goes out, so a single bad entry can't take down a
server.
Scope-limited vs PR #1456:
* SSE legacy transport intentionally not threaded (follow-up).
The PR didn't cover it; modern MCP servers are Streamable HTTP.
* No env-var interpolation in v0.8.31 — headers are sent
literally, matching the PR. Documented in the field doc so
users know tokens pasted directly into mcp.json live there
as plain text. `${VAR}` substitution is a follow-up.
8 new tests (the original PR shipped without any): config
round-trip with custom headers, empty headers omitted from
serialized output, accept-normal-auth, reject empty key, reject
CR/LF in value, reject Accept/Content-Type override (case-
insensitive), and StreamableHttpTransport stores headers.
Empty-headers MCP fixtures updated at 10 sites across mcp.rs and
main.rs to match the new struct shape.
Harvested from PR #1451 by @Oliver-ZPLiu (closes part of #1450).
Token-budget control for read_file: large files no longer drop their
entire contents into the conversation context on every turn.
Default window is 200 lines / ~16 KB; the hard cap is 500 lines.
Small files (≤ 200 lines AND ≤ 16 KB, no explicit range params) keep
the historical raw-contents return so existing prompts that read
config files / single source files see no behavior change. Otherwise
the response is wrapped in a `<file …>` tag with line-numbered
content, `shown_lines`, `truncated`, and `next_start_line`
attributes, plus a `[TRUNCATED]` hint so the model can page through
in 16 KB slices.
Cleanups from the original PR while harvesting:
- shown_lines is now 1-based inclusive (e.g. "3-6"), matching
start_line / next_start_line / the line-number prefix on each
rendered row. The original PR mixed 0-based indices in attributes
with 1-based numbers in body output, which was confusing.
- The continuation hint mirrors that 1-based range so model
reasoning over "what did I just see?" is unambiguous.
- Added 6 unit tests covering: small-file fast path, explicit
range wrap-in-file-tag with 1-based lines, out-of-range
no-content sentinel, zero start_line / max_lines rejection,
hard-cap clamp at 500 lines, and large-file no-range default
window. The original PR shipped without tests.
Ptyxis 50.x (the new default terminal on Ubuntu 26.04) ships with
VTE 0.84.x, which parses the `\x1b[?2026h` / `\x1b[?2026l` synchronized-
output begin/end pair but still flashes the entire viewport on every
wrapped frame instead of deferring rendering. gnome-terminal 3.58 on
the same VTE renders cleanly, so the heuristic stays narrow: trigger
only on TERM_PROGRAM matching `ptyxis` (case-insensitive) or
PTYXIS_VERSION non-empty.
Add a new `synchronized_output` setting (`auto` | `on` | `off`,
default `auto`) controlling whether the renderer wraps each frame in
DEC 2026. `apply_env_overrides` flips `auto` → `off` when Ptyxis is
detected; the four wrapping sites in ui.rs (`draw_app_frame_inner`,
`reset_terminal_viewport`, `resume_terminal`, and the early-init
viewport reset) now respect the resolved flag. Users on Ptyxis who
upgrade past an upstream fix or want to confirm one landed can
override with `/set synchronized_output on`.
8 new tests cover: default-auto resolves enabled, off disables,
on stays enabled, set/aliases, Ptyxis via TERM_PROGRAM, Ptyxis via
PTYXIS_VERSION alone, explicit `on` beats the heuristic, explicit
`off` is preserved, and no non-Ptyxis TERM_PROGRAM (including Ghostty
and VS Code, which both keep DEC 2026 on) regresses.
Reported via WeChat by Cyrux on Ubuntu 26.04 with v0.8.30 npm install;
analysis by Hunter pinpointed Ptyxis + VTE 0.84 as the cause.
- workspace.package.version: 0.8.29 → 0.8.30
- per-crate path-dependency version pins: 0.8.29 → 0.8.30
- npm/deepseek-tui: version + deepseekBinaryVersion → 0.8.30
- Cargo.lock refreshed via `cargo update --workspace --offline`
- CHANGELOG: `[Unreleased]` → `[0.8.30] - 2026-05-11` with the full
release-theme paragraph and the new "Changed" section for the
Alt+<key> unification
Verified with `./scripts/release/check-versions.sh`:
Version state OK: workspace=0.8.30, npm=0.8.30, lockfile in sync.
v0.8.29 spot-fixed `g` with a gg double-tap (commit c13ddb04d), but
the underlying bug class still affected `G`, `[`, `]`, `?`, `l`, and
both `v`/`V`: bare press on an empty composer hijacked the keystroke
for transcript navigation, swallowing the first character of a
message. Even the gg fix itself only suppressed the SCROLL — the
first `g` was still eaten, so typing "good morning" produced "ood
morning" with no whale and no warning.
Unified fix: all seven bindings now require the `Alt` modifier (same
pattern as the existing `Alt+R` history search and `Alt+V` tool
details). Plain letters always insert as text:
Alt+G → scroll to top
Alt+Shift+G → scroll to bottom
Alt+[ / Alt+] → previous / next tool output
Alt+? → open searchable help (F1 / Ctrl+/ also bound)
Alt+L → pager for the last message
Alt+V → tool-details pager (was already bound; only path now)
The `App::transcript_pending_g` field from the v0.8.29 half-fix is
removed along with its Esc / Enter / Char-catch-all resets. The
existing helper `details_shortcut_modifiers` (which accepted bare,
Shift, and Alt-only — the permissive predicate that ate the bare `v`
keystroke) is replaced by `alt_nav_modifiers`, which requires `Alt`,
allows `Shift`, and blocks `Ctrl` / `Super` so the bindings don't
collide with platform clipboard or window-management shortcuts.
Same modifier vocabulary as `Alt+R` / `Alt+P` / `Alt+1..3`, so this
makes the keymap more consistent rather than introducing a new
convention.
Regression-guarded by `alt_nav_modifiers_require_alt_and_exclude_ctrl_super`
in `crates/tui/src/tui/ui/tests.rs`, which exercises every modifier
combination the predicate needs to accept or reject. Full
`cargo test -p deepseek-tui` (2751 tests) passes; clippy clean; fmt
clean.
User-facing migration: any user who learned the bare-letter nav
shortcuts in v0.8.x needs to add `Alt+`. The trade-off is unambiguous
— losing the first letter of "good", "great", "let", "list", "very",
"verify", and anything starting with `?` was burning more users than
the bare-letter shortcuts were serving.
The whale was a 12-frame animated indicator (`🐳, 🐳., 🐳.., 🐳..., 🐳..,
🐳., 🐋, 🐋., 🐋.., 🐋..., 🐋.., 🐋.`) that shipped from v0.3.5 onward
and rendered in the top-right status cluster of the header. Commit
`1a04659a9` ("smoother TUI streaming") quietly swapped it for a 6-frame
geometric ring (`◍ ◉ ◌ ◌ ◉ ◍`); `f4dbf828c` later deleted the function
entirely. Nothing in the CHANGELOG mentioned either step, and the
absence has been on the maintainer's mind ever since.
This commit restores the whale as a configurable status indicator that
sits immediately before the reasoning-effort chip ("next to max"):
- `widgets/header.rs` gains a public `header_status_indicator_frame`
helper and a `HeaderData::with_status_indicator(Option<&'static str>)`
builder. The frame computation is pure (keyed off `turn_started_at`
and the mode string) so the widget itself stays a stateless render.
- The chip renders as the first item in the status cluster, before
`provider` / `effort` / `Live` / context. Idle state shows a steady
🐳; an active turn cycles frames every 420 ms (same cadence as the
original v0.3.5 implementation).
New setting `status_indicator`:
- `whale` (default) — restored historical cycling.
- `dots` — the 6-frame geometric replacement, for users who came in
during the dots era and prefer it.
- `off` — hide the chip entirely.
Settable via `/config status_indicator <whale|dots|off>`, persisted in
`settings.toml`, mirrored in the typed `config_ui::SettingsSection`
with a new `StatusIndicatorValue` enum so the web/JSON config surface
sees it too.
Default-to-whale rationale: this restores the historical behaviour for
every user, including those who never realized the whale was gone, and
keeps the "🐳 in /config" delight that the project's name has always
implied.
Regression-guarded by seven new tests in `widgets/header.rs::tests`
covering idle frame, frame advancement, dots variant, off variant
including aliases, unknown-mode fallback to whale, render placement
before the effort label, and confirmation that `off` hides the chip
without disturbing the effort chip layout.
The previous commit (15525751c) did two things in one shot:
1. Decoupled the footer water-spout gate from `low_motion`, so
`low_motion = true` no longer hides the wave when `fancy_animations
= true`.
2. Re-wired the wave's frame source from wall-clock milliseconds
to a per-turn character-commit counter, on the theory that the
wave should visually move at the same cadence as the text on
screen ("water = typing").
The user-visible result of (2) was that the wave looked notably
different than in v0.8.29 — slower, sluggish, less alive. Root cause:
the sine math in `footer_working_strip_glyph_at` (`t = frame / 1000.0`,
primary term × 8.0) was tuned for frame ≈ 1000 units/sec, which is
what wall-clock ms produces. Driving frame off character commits
gives ~10–30 units/sec, so the wave evolves ~30× slower than the
intended tuning. Theoretically fixable by re-tuning the sine
constants, but that's a bigger change with its own visual
regressions to vet, and the user explicitly asked to "put it back
to where it was."
This commit reverts only (2):
- Removes `StreamingState::stream_commit_frame` field.
- Removes the increment in `commit_text` and `finalize_block_text`.
- Removes the zeroing in `reset`.
- Removes the five `stream_commit_frame_*` regression tests.
- Changes `render_footer` to assign `Some(now_ms)` again instead of
`Some(app.streaming_state.stream_commit_frame)`.
The decoupling from (1) stays: the gate is still
`if app.fancy_animations { ... }`, so `low_motion = true` no longer
hides the wave. The settings.rs docstrings stay updated.
CHANGELOG entry is collapsed to a single short bullet describing the
decoupling-only fix.
Net effect for users: the wave looks and feels exactly like v0.8.29,
but `low_motion = true` now keeps the whale visible (was the
original regression that started all of this).
The water-spout strip in the footer used to be hard-gated by `!low_motion`,
which meant the typewriter-streaming option silently killed the spout
animation — even with `fancy_animations = true` the strip stayed plain
whitespace. Users testing the typewriter pacing in v0.8.29 reported "where
did the whale go," which is on us: we'd collapsed two concerns
(streaming pacing vs footer animation) onto one flag.
This commit makes the two flags orthogonal:
- `low_motion` governs streaming pacing only (typewriter = one char per
commit tick vs upstream cadence = drain everything queued).
- `fancy_animations` governs whether the spout-strip is rendered at all.
It also wires in a new idea that fell out naturally once the two were
decoupled: instead of driving the wave animation off wall-clock
milliseconds, drive it off a per-turn character-commit counter
(`StreamingState::stream_commit_frame`). The wave then visually moves at
the same cadence as the text:
- Typewriter mode → wave drips at one frame per character.
- Upstream mode → wave surges when V4-pro bursts a warm-cache turn.
- Tool calls and planning pauses → no chars arrive, wave freezes. The
textual `working...` pulse still ticks on wall-clock, so a heartbeat
is always visible.
- New turn (`StreamingState::reset`) → counter zeroes so each turn
opens with a fresh wave shape.
`stream_commit_frame` is a `u64` advanced inside `commit_text` and
`finalize_block_text` by the character count of each committed slice,
so multi-byte UTF-8 (e.g., CJK) advances the wave by one glyph per
character rather than three frames per character — matching the
visual weight of each glyph.
Regression-guarded by five new tests in `crates/tui/src/tui/streaming/mod.rs`:
- `stream_commit_frame_advances_by_character_count_on_commit`
- `stream_commit_frame_counts_unicode_chars_not_bytes`
- `stream_commit_frame_advances_on_finalize`
- `stream_commit_frame_resets_on_reset`
- `stream_commit_frame_freezes_when_no_text_arrives`
Also folds in `cargo fmt` cleanup for two files where prior commits on
this branch landed without re-formatting (`crates/tui/src/tui/ui.rs`
around the new Esc-arm wrapper introduced for the `gg` double-tap, and
the new `fireworks_custom_base_url_preserves_provider_model` test in
`crates/config/src/lib.rs`). No behavior change from those edits.
Settings doc comments in `crates/tui/src/settings.rs` updated to spell
out the new orthogonal semantics so the next maintainer doesn't have
to reverse-engineer it from `render_footer`.
CHANGELOG entry added under a new `[Unreleased]` section.
A single bare 'g' with an empty composer was hijacked as a scroll-to-top
command, preventing users from typing 'g' as the first character of a message.
The transcript would jump to line 0 instead of inserting 'g' into the composer.
Change to a vim-style 'gg' double-tap: first 'g' arms transcript_pending_g,
second 'g' executes the scroll. Any other character input, Enter, or Escape
resets the pending flag so a stray 'g' during composition arms without
scrolling.
Also adds transcript_pending_g field to App struct (default false).
Cherry-picked from PR #1475 by CrepuscularIRIS (autoghclaw/issue-828).
When a shell command spawns background subprocesses (nohup, sleep &, etc.),
those subprocesses inherit the pipe write-ends. After the shell exits, the
subprocesses keep those write-ends open, causing handle.join() on reader
threads to block indefinitely in read(). Since list_jobs() calls poll() →
collect_output() on every TUI render tick, the entire UI event loop blocks.
Fix: kill the process group (PGID = child PID) before joining reader threads,
so orphaned subprocesses release their pipe write-ends. Also wires the
previously dead-coded cleanup() into list_jobs() with a 1-hour eviction
window to bound process table growth.
Fixes#828.
Previously only OpenRouter was whitelisted via provider_preserves_custom_base_url_model,
causing six other providers (Sglang, Novita, Fireworks, Vllm, Ollama, NvidiaNim) to still
rewrite user-configured model names when a custom base URL was set. Users routing through
their own gateway would get 400s because the TUI sent provider-prefixed model names
(e.g. accounts/fireworks/models/deepseek-v4-pro) that the gateway didn't recognise.
The fix removes the provider-specific guard: when base_url_is_custom_for_provider()
returns true (i.e. the user set a non-default endpoint), the model name is preserved
as-is for every provider, not just OpenRouter.
Affected:
- crates/config/src/lib.rs: ProviderKind::Openrouter guard removed
- crates/tui/src/config.rs: ApiProvider::Openrouter guard removed
- Test: fireworks_custom_base_url_preserves_provider_model added
- Test: nvidia_nim_reads_facade_provider_table updated for new behaviour
Addresses the #857 class bug (B1 in the v0.8.30 audit).
The Ctrl+O thinking-pager arm guarded on
`key.modifiers == KeyModifiers::CONTROL` (exact match), so any
additional modifier bit set by the terminal — Shift while a
native-selection mouse bypass was active, Caps Lock indicator on
some keyboard layouts — silently fell through to the $EDITOR arm at
ui.rs:2833 and did nothing visible when the composer was empty. The
user saw the "thinking collapsed; press Ctrl+O for full text"
affordance, pressed it, and the handler appeared to ignore them.
Relaxed to `contains(KeyModifiers::CONTROL)` to match the established
pattern at Ctrl+P (ui.rs:2068) and Ctrl+B (ui.rs:2077). With the
existing `app.input.is_empty()` guard preserved, the $EDITOR arm
still owns the non-empty-composer case, so the two handlers continue
to partition Ctrl+O cleanly.
Also documents the two-binary install gotcha in AGENTS.md: the CLI
dispatcher (`crates/cli` → `deepseek`) and the TUI runtime
(`crates/tui` → `deepseek-tui`) ship as separate executables, and
`cargo install --path crates/cli` alone leaves the TUI stale — which
is how both this fix and the active_cell fix from dc2433a8b
initially appeared to be no-ops during local maintainer testing.
The release pipeline packages both binaries, so end users were
never affected by that side; this is purely a maintainer-local
footgun and is now spelled out for future agents.
Extends the existing v0.8.29 CHANGELOG entry to credit both halves
of the Ctrl+O fix.
After `ThinkingComplete` the finalized thinking entry sits in
`app.active_cell` with `streaming = false` until the active cell
flushes to history at end-of-turn. During that window the transcript
rendered the "thinking collapsed; press Ctrl+O for full text"
affordance from `render_thinking`, but `open_thinking_pager` only
searched `app.history` — so the handler surfaced "No thinking blocks
to expand" while pointing at the affordance. The affordance was
truthful; the handler was lying.
Routed the lookup through `cell_at_virtual_index` /
`virtual_cell_count`, the existing virtual-index API that
`open_tool_details_pager` already uses for the same active-cell
window. The selection-based path resolves through the virtual index
too, so dragging into an in-flight thinking block and pressing
Ctrl+O now works as well.
Regression guard: `open_thinking_pager_finds_thinking_in_active_cell`
drives the entry into active_cell, finalizes it so the "collapsed"
affordance is what render_thinking emits, then asserts Ctrl+O pushes
the Pager view instead of surfacing the "No thinking blocks" status.
On platforms where mouse capture is disabled by default (Windows CMD /
legacy conhost), the terminal sends mouse-wheel events as Up/Down arrow-
key sequences. Without composer_arrows_scroll those sequences cycle the
input history instead of scrolling the transcript (#1443).
Set the default for composer_arrows_scroll to !use_mouse_capture so that
terminals that forward wheel events as arrows get page-scrolling out of the
box, while terminals with real mouse capture (Windows Terminal, Linux, macOS)
keep the existing history-navigation default.
The explicit [tui] composer_arrows_scroll config key still overrides the
derived default in both directions.
Also enable mouse capture by default for ConEmu/Cmder (ConEmuPID env var),
which handles VT mouse-mode reporting cleanly, giving those users in-app
scrolling without needing --mouse-capture.
Fixes#1443
Signed-off-by: CrepuscularIRIS <serenitygp@qq.com>
When exec_shell runs a Docker build on macOS and Docker Desktop's signed
process has written com.apple.provenance-tagged files under
~/.docker/buildx/activity/, the child process spawned by the TUI
sandbox gets EPERM when it tries to update those files, producing:
failed to update builder last activity time: open
/Users/.../.docker/buildx/activity/.tmp-...: operation not permitted
Add looks_like_macos_provenance_failure() to detect this pattern via
three heuristics (provenance xattr mention, activity-time message, or
buildx/activity path + EPERM), with an early-return guard that suppresses
the hint on clean exits. Wire the hint into both the foreground exec_shell
path and build_shell_delta_tool_result so it surfaces on background task
polls too.
Four unit tests cover the positive cases and the two guard cases (exit 0,
unrelated EPERM).
Closes#1449
Signed-off-by: CrepuscularIRIS <serenitygp@qq.com>
Ghostty's GPU compositor flash-renders each full-screen repaint at 120 FPS,
producing visible flicker identical to the VS Code issue fixed in #1356.
Extend apply_env_overrides() to also force low_motion=true +
fancy_animations=false when TERM_PROGRAM=ghostty, capping redraws to 30 FPS.
Add ghostty_term_program_forces_low_motion_on test mirroring the existing
vscode test, serialised through the process-wide lock_test_env() guard.
Fixes#1445
Signed-off-by: CrepuscularIRIS <serenitygp@qq.com>
Emoji in U+1F000+ have no stable column-width contract across terminal
emulators. On cmd.exe/PowerShell they render as 1-column placeholder
boxes even though unicode_width reports 2; on WezTerm/Alacritty with
certain font stacks the rendered width can be off by one column. Both
cases break layout arithmetic in the header and file-tree widgets.
Changes:
- header.rs: replace 🐳 (U+1F433, 2-wide) with ◆ (U+25C6, always 1-wide)
in the "max" reasoning-effort chip
- file_tree.rs: drop the 📁/📄 (U+1F4C1/U+1F4C4) entry-icon prefix; the
▼/▶ expand marker already distinguishes dirs from files
Fixes#1314
Tighten session workspace Git root detection so invalid parent .git
markers are not treated as real repositories. This prevents unrelated
temporary workspaces from being scoped together when a stray .git
directory exists under /tmp.
Also move env-mutating tests onto the shared test env lock and make the
streamable HTTP MCP mock server serve until the test ends, avoiding
parallel test races and premature mock server shutdowns.
(cherry picked from commit eecfc16fc99d072ac389980ec9e5e3f208297b8e)
Keep individual skills out of the top-level slash command menu so large
skill collections do not crowd out built-in commands.
Skills still complete after `/skill`, including both the full skill list
after `/skill ` and prefix matches after `/skill <prefix>`.
(cherry picked from commit 57f8e3ad84dad9cf46290c0dc23e2b26504196df)
`requires_reasoning_content()` only matched literal `deepseek-v4*` model
IDs, but `deepseek-chat` and `deepseek-reasoner` are DeepSeek's public
API aliases that resolve server-side to `deepseek-v4-flash` and
`deepseek-v4-pro` respectively. Both have thinking mode enabled by
default, so when a user sets `default_text_model = "deepseek-chat"` (the
value `deepseek auth` / onboarding writes), the thinking-mode sanitizer
is skipped and tool-call assistant messages are sent without
`reasoning_content`. DeepSeek then rejects the second turn with:
HTTP 400: The `reasoning_content` in the thinking mode must be passed
back to the API.
Extend `requires_reasoning_content()` to recognise the `deepseek-chat`
and `deepseek-reasoner` alias prefixes (covering suffixed variants like
`deepseek-chat:free` used by proxied deployments). The explicit
`reasoning_effort = "off"` escape hatch still disables replay via the
unchanged `should_replay_reasoning_content()` check.
Adds `alias_thinking_detection_tests` covering the aliases, explicit V4
IDs (regression guard), excluded non-thinking models, suffixed variants,
and the reasoning-off override.
Refs: https://api-docs.deepseek.com/guides/thinking_mode
(cherry picked from commit 46941142123827fa16fc9a1fb41b78c293e935ce)
Return a schema hydration result on first deferred tool use so the model can retry with visible parameters instead of executing guessed arguments. Add edit_file coverage for old_string/new_string aliases.
(cherry picked from commit 91be171cc15dd895170bd1a486445f5e05356b57)
Accept both LF and CRLF SSE event separators in the MCP SSE transport so
uvicorn and FastMCP servers can publish endpoint events correctly.
Add regression coverage for CRLF endpoint discovery.
PR #1421 from @reidliu41. Filters SGR mouse-report bursts that some terminal chains leak into stdin while mouse capture is enabled, while preserving ordinary coordinate-like text.
Community feedback on the v0.8.29 follow-up (WeChat thread on
#1118) made a sharp point: the standard Western-LLM advice
"always write prompts in English" doesn't transfer to DeepSeek
V4, which is a Chinese-first multilingual model with a
Chinese-co-trained tokenizer. `你好` typically encodes to ~1
token, not 2; the "Chinese is expensive" framing is folk wisdom
from a different model family.
The naïve translation of that argument is "ship a fully
translated base.md per locale" — and that's the move v0.9.x
might eventually make. For v0.8.29 we deliberately stop at the
bookend (preamble + closer in native script, English middle)
because of three concrete costs:
1. Drift risk between N translated copies of a 200-line
prompt — every rule change has to land in lockstep.
2. Cache stability — one English `base.md` lets us share
prefix-cache state across locales for the workspace-
static portion of the prompt.
3. Translation QA expense — 95% right is bad, because the
missing 5% becomes silent behavior divergence.
Captured all of this in the `locale_reinforcement_preamble`
docstring so the next maintainer reading the prompt-assembly
code sees the design tension and the cost model explicitly,
and knows full translation is the natural next step if the
bookend stops being sufficient.
No runtime change; documentation only. Credit @MuMu (via Hunter)
for the bookend pattern that motivates this design, and the
unnamed WeChat commenter who made the tokenizer-economics
argument that motivates this docstring expansion.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
GitGuardian's "Basic Auth String" detector flagged commit 09dcbede0
because the test fixture for `redact_proxy_userinfo_strips_password`
contained literal URL strings of the shape
`scheme://username:password@host` — `alice:hunter2` and `bob`. The
values are obvious placeholders (not real credentials), but the
detector's regex is shape-based: any scheme-prefixed colon-separated
userinfo segment terminated by `@` matches, regardless of whether the
content is a real secret.
The test still needs to exercise the redaction logic for credential-
carrying proxy URLs. Fix: assemble the URLs via `format!` from
explicit placeholder constants (`PLACEHOLDER_USER`,
`PLACEHOLDER_PASS`) so the literal source text never contains a
contiguous `scheme://name:secret@host` pattern. Runtime behavior is
identical — `redact_proxy_userinfo` receives the same string and
returns the same redacted form.
Also reworded the function docstring (line 61) and the inline comment
at the warning log site (line 993) to describe the userinfo segment
without spelling out a literal `user:pass@host` shape that the same
detector could later trip on.
Two preexisting fixtures elsewhere in this file
(`mask_url_secrets("https://user:s3cret@…")` at line 3155 and its
docstring at line 46) have been on `main` for several releases and
are presumably already on GitGuardian's allowlist — left untouched
in this commit so the fix scope stays minimal. If they re-fire on a
future scan, the same `format!` pattern can be applied there.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The opening preamble from commit `47f6d69e5` works for the first
few turns, but as English context accumulates in the session (code
read into the transcript, error logs, file listings, search
results, project context), the transformer's recency bias pulls
`reasoning_content` back toward English even when the user keeps
writing in their own language. The empirical fingerprint is "model
thinks in Chinese for the first 3-4 turns, then quietly switches
to English thinking around turn 5 as more code lands in context."
Community feedback (WeChat thread on #1118 — @MuMu describes an
XML-tagged "bilingual bookend" pattern they used in another
project, and @益达 confirms the translation-accuracy problem with
fully-translated prompts) pointed at the bookend pattern: keep the
rule-heavy middle of the prompt in English (single source of
truth, model is natively multilingual), but reinforce the locale
directive at BOTH ends in native script. The opening anchors
behavior at session start; the closer sits at the maximum-
recency position right before the user's next message and
re-asserts the rule each turn.
`locale_reinforcement_closer()` returns Some for `zh-Hans` /
`zh-CN` / `zh`, `ja` / `ja-JP`, `pt-BR` / `pt`. English (and
unmatched locales) return None — system prompt stays
byte-identical to the previous behavior for English users.
The closer is appended after the previous-session handoff block
(the existing "last block" position), so it's the very last
content before the user's first message. Any future block that
needs to sit closer to the user should be added BEFORE the
closer with an updated test invariant.
Three new tests pin the contract:
* `locale_reinforcement_closer_returns_native_script_for_supported_locales`
— each supported locale's closer is in its native script and
explicitly mentions `reasoning_content` (the V4 knob).
* `system_prompt_bookends_zh_hans_with_preamble_and_closer` —
the full zh-Hans system prompt contains both `## 语言要求`
(preamble) and `## 语言再次提醒` (closer), in that order, and
no other top-level `##` section follows the closer.
* `system_prompt_skips_locale_preamble_for_english` (extended)
— English locale gets neither the preamble nor any of the
three locale closers.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
PR #1408's MCP proxy support (commit 865db6248) added a
`tracing::warn!` for malformed `HTTPS_PROXY` values that included
the raw URL via `proxy = %proxy_url`. With v0.8.29's new
file-backed tracing subscriber (writing to
`~/.deepseek/logs/tui-YYYY-MM-DD.log`), that means a corporate
proxy URL of the shape `http://user:pass@proxy.example/` would
leak the password to disk whenever reqwest rejected the URL.
Fix: redact the `user:pass@` userinfo segment before logging via
a new `redact_proxy_userinfo()` helper. `http://alice:hunter2@proxy/`
becomes `http://***@proxy/`. URLs without userinfo are returned
unchanged; the `@` is only treated as a userinfo separator when it
appears before any `/`, `?`, or `#` (so path-embedded `@` doesn't
trigger redaction). Garbage input (no `://`) passes through — the
warning log site is already in the malformed-URL failure path.
Pinned by `redact_proxy_userinfo_strips_password` covering five
cases: full creds, user-only, no-userinfo, path-only-`@`, and
garbage. The non-malformed path (where reqwest accepts the URL)
never logs the URL at all, so this is the only leak vector.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`base.md` stays the single source of truth (English meta-language,
DeepSeek V4 is natively multilingual, prefix-cache stable across
users in the same locale). For non-English UI locales we now prepend
a short locale-native passage so the model's first exposure to the
prompt is an explicit "think and reply in {locale}" directive in the
user's own writing system — defeats the failure mode reported in
#1118 and visible in the recent WeChat screenshot where a user with
`locale = zh-Hans` configured still got English thinking because the
task context (Rust code, English log lines) overpowered the inferred
`## Environment.lang` signal.
Locales supported (matched against `PromptSessionContext.locale_tag`,
which the caller resolves from `Settings`):
* `zh-Hans` / `zh-CN` / `zh` — Simplified Chinese preamble
* `ja` / `ja-JP` — Japanese preamble
* `pt-BR` / `pt` — Brazilian Portuguese preamble
English (and any unmatched locale) returns `None` and the system
prompt is byte-identical to v0.8.28 — so this is a strict additive
change for non-English users.
Each preamble is ~6-8 lines and explicitly:
* names the runtime ("DeepSeek TUI") so the model knows it's not
switching personas
* declares the directive for BOTH `reasoning_content` and the final
reply (the V4 knob that #1118 hinges on)
* preserves tool-name immutability (`read_file`, `exec_shell`,
paths, env vars, CLI flags, URLs stay in their original form)
* handles mid-session language switches (next-turn switching)
* defers to explicit user override ("think in English" etc.)
Three new tests pin the contract:
* `locale_reinforcement_preamble_returns_native_script_for_supported_locales`
— preamble must be in the locale's native script, must mention
`reasoning_content`, and must call out tool-name immutability;
English/unknown locales must return `None`.
* `system_prompt_prepends_locale_preamble_for_zh_hans` — the
preamble must appear *before* the English base prompt body in
the assembled system prompt (attention precedence + cache
ordering both depend on this).
* `system_prompt_skips_locale_preamble_for_english` — English
locale must produce a byte-identical prompt to the pre-feature
behavior (no zh / ja / pt strings anywhere).
Prefix-cache impact: per-locale cache shards stay intact (a
zh-Hans user's prompt shares the preamble across turns; an English
user's prompt is unchanged). Cross-locale cache is invalidated,
which is correct — different users in different locales were never
sharing cache for the right reasons.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Bumps version 0.8.26 → 0.8.29 and toolCount 61 → 62 (new tool from
the v0.8.28 / v0.8.29 cycle landed on the canonical surface).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CHANGELOG.md gains a `[0.8.29]` section above `[0.8.28]` covering
the scroll-demon structural fix, the #1395 wrong-project Ctrl+R
fix, MCP HTTP proxy support, MCP discovery skip-malformed, note
commands, AGENTS.md merge, CJK Auto routing, sync-cnb hardening,
and the 4-PR test coverage batch.
README.md and README.zh-CN.md "What's New" sections rewritten to
match (v0.8.27 → v0.8.29). The `prompts::tests::changelog_entry_exists_for_current_package_version`
integration test pins the CHANGELOG-must-have-current-version
invariant.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`reqwest 0.13` does not auto-detect proxy env vars by default, so MCP
HTTP connections were bypassing the proxy that every other tool on
the user's box (curl, npm, git, …) was using. Users behind corporate
egress proxies and China-mainland setups routing through a local
Clash / Shadowsocks tunnel had their MCP servers fail to connect or
silently leak around the tunnel.
When the `MCP HTTP transport client builder` runs, we now read
`HTTPS_PROXY` / `https_proxy` / `HTTP_PROXY` / `http_proxy` (first
non-empty wins) and route via `reqwest::Proxy::all(...)`. `NO_PROXY`
is honored via `reqwest::NoProxy::from_env()`. Malformed proxy URLs
log a `tracing::warn!` (no scroll-demon leak — see runtime_log) and
the connection proceeds without a proxy rather than failing the
whole MCP attach.
Closes#1408. Thanks @hlx98007 for the report.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Hunter Bown