KIMI_CODE_LEGACY_FLAG silently ignored by interactive TUI and print mode in 0.43.1

Summary

KIMI_CODE_LEGACY_FLAG=1 is silently ignored by both the interactive TUI and kimi -p in 0.43.1 — sessions start on the agent-core-v2 engine regardless of the flag. In 0.41.0 the same setup correctly falls back to the legacy engine. The changelog documents this removal only for kimi acp (0.40.0); the TUI and print-mode removals are not documented anywhere.

Environment

• Windows 11, native single-binary install (~/.kimi-code/bin/kimi.exe)
• Launch env: KIMI_CODE_LEGACY_FLAG=1, KIMI_CODE_HOME set explicitly
• Model via KIMI_MODEL_* env (provider type kimi, model kimi-k3)

Expected (0.41.0, same launcher)

Session evidence markers:

• wire.jsonl line 1: "protocol_version":"1.4"
• session log line 1: provider=kimi
• [[permission.rules]] fully honored: allow-listed literal commands run without prompts; deny rules hard-refuse.

Actual (0.43.1, same launcher)

Both a new interactive TUI session and a kimi -p session show:

• wire.jsonl line 1: "protocol_version":"1.5"
• session log line 1: provider=openai

i.e. the v2 engine despite KIMI_CODE_LEGACY_FLAG=1.

Consequence (consistent with #2100, which is still open): under v2 the user [[permission.rules]] are not loaded —

• allow rules dead: an allow-listed literal command (date) triggered a manual approval prompt;
• deny rules dead: git push origin master (in an isolated test repo) was NOT refused by the configured deny rule (it was only stopped by an external PreToolUse hook we run ourselves).

So 0.43.1 removes the last fallback for users who depend on permission.rules: previously the legacy engine provided a working path; now every surface (acp since 0.40.0, and TUI/-p as of this release) forces v2, where rules are ignored.

Changelog gap

• 0.40.0 changelog: "The kimi acp subcommand no longer honors KIMI_CODE_LEGACY_FLAG" — documented.
• 0.42.0 / 0.43.0 / 0.43.1 changelog: no mention of TUI or print mode dropping the flag.

Request

1. Confirm whether dropping KIMI_CODE_LEGACY_FLAG for TUI and -p is intentional.
2. If intentional: please document it in the changelog and publish the migration path / sunset timeline for deployments that rely on [[permission.rules]] (which require the legacy engine today, cf. #2100).
3. If unintentional: please restore the flag for TUI and -p.

Happy to provide wire logs, session logs, or a minimal repro script if useful.

Start by tracing how KIMI_CODE_LEGACY_FLAG is handled for the interactive kimi command and kimi -p, then compare the 0.41.0 and 0.43.1 behavior using the reported protocol and provider markers. Done means confirming whether the removal is intentional and either documenting the migration and sunset timeline or restoring the flag, with permission.rules behavior verified.