@maincode-ai/matilda-code 0.21.12 → 0.21.13-nightly.20261026.e0eae1d8c

package/bundled/mainy/docs/features/hooks.md

@@ -51,12 +51,14 @@ Command hooks execute commands via child processes. Input JSON is passed through
 | `command`       | `string`                 | Yes      | Command to execute                          |
 | `name`          | `string`                 | No       | Hook name (for logging)                     |
 | `description`   | `string`                 | No       | Hook description                            |
-| `timeout`       | `number`                 | No       | Timeout in milliseconds, default 60000      |
+| `timeout`       | `number`                 | No       | Timeout in seconds, default 60              |
 | `async`         | `boolean`                | No       | Whether to run asynchronously in background |
 | `env`           | `Record<string, string>` | No       | Environment variables                       |
 | `shell`         | `"bash" \| "powershell"` | No       | Shell to use                                |
 | `statusMessage` | `string`                 | No       | Status message displayed during execution   |
 
+`timeout` is in seconds for command, HTTP and prompt hooks, as in Claude Code; SDK-registered function hooks keep milliseconds. Earlier versions read command hook timeouts as milliseconds, so rewrite any such value in seconds, for example `10000` as `10`; otherwise it is read as 10000 seconds. A command hook `timeout` that is not a positive number, such as `"30s"`, is ignored and the 60 second default applies, and one longer than about 24.8 days, the longest a timer supports, is capped there.
+
 **Example:**
 
 ```json
@@ -70,7 +72,7 @@ Command hooks execute commands via child processes. Input JSON is passed through
             "type": "command",
             "command": "$MATILDA_PROJECT_DIR/.matilda/hooks/security-check.sh",
             "name": "security-check",
-            "timeout": 10000
+            "timeout": 10
           }
         ]
       }
@@ -942,7 +944,7 @@ exit 0
             "type": "command",
             "command": "$HOME/.matilda/hooks/todo-validator.sh",
             "name": "todo-validator",
-            "timeout": 5000
+            "timeout": 5
           }
         ]
       }
@@ -1036,7 +1038,7 @@ exit 0
             "type": "command",
             "command": "$HOME/.matilda/hooks/todo-completion-validator.sh",
             "name": "completion-validator",
-            "timeout": 5000
+            "timeout": 5
           }
         ]
       }
@@ -1069,7 +1071,7 @@ Hooks are configured in Matilda Code settings, typically in `.matilda/settings.j
             "command": "/path/to/security-check.sh",
             "name": "security-check",
             "description": "Run security checks before tool execution",
-            "timeout": 30000
+            "timeout": 30
           }
         ]
       }
@@ -1120,7 +1122,7 @@ Only `command` type supports asynchronous execution. Setting `"async": true` run
             "type": "command",
             "command": "$MATILDA_PROJECT_DIR/.matilda/hooks/run-tests-async.sh",
             "async": true,
-            "timeout": 300000
+            "timeout": 300
           }
         ]
       }
@@ -1206,7 +1208,7 @@ Configure in `.matilda/settings.json`:
             "command": "${SECURITY_CHECK_SCRIPT}",
             "name": "security-checker",
             "description": "Security validation for bash commands",
-            "timeout": 10000
+            "timeout": 10
           }
         ]
       }

package/bundled/mainy/docs/features/language.md

@@ -21,7 +21,6 @@ This is the CLI’s UI localization layer (i18n/l10n): it controls the language
 Use the `/language ui` command:
 
 ```bash
-/language ui zh-CN    # Chinese
 /language ui en-US    # English
 /language ui ru-RU    # Russian
 /language ui de-DE    # German
@@ -34,7 +33,6 @@ Use the `/language ui` command:
 Aliases are also supported:
 
 ```bash
-/language ui zh       # Chinese
 /language ui en       # English
 /language ui ru       # Russian
 /language ui de       # German
@@ -67,7 +65,6 @@ The LLM output language is controlled by a rule file at `~/.matilda/output-langu
 
 On first startup, if no `output-language.md` file exists, Matilda Code automatically creates one based on your system locale. For example:
 
-- System locale `zh` creates a rule for Chinese responses
 - System locale `en` creates a rule for English responses
 - System locale `ru` creates a rule for Russian responses
 - System locale `de` creates a rule for German responses
@@ -81,13 +78,12 @@ On first startup, if no `output-language.md` file exists, Matilda Code automatic
 Use `/language output <language>` to change:
 
 ```bash
-/language output Chinese
 /language output English
 /language output Japanese
 /language output German
 ```
 
-Any language name works. The LLM will be instructed to respond in that language.
+The LLM will be instructed to respond in that language.
 
 > [!note]
 >
@@ -110,7 +106,7 @@ Any language name works. The LLM will be instructed to respond in that language.
 ### Via Environment Variable
 
 ```bash
-export MATILDA_CODE_LANG=zh
+export MATILDA_CODE_LANG=de
 ```
 
 This influences auto-detection on first startup (if you haven’t set a UI language and no `output-language.md` file exists yet).
@@ -129,29 +125,6 @@ User directory takes precedence over built-in translations.
 > Contributions are welcome! If you’d like to improve built-in translations or add new languages.
 > For a concrete example, see [PR #1238: feat(i18n): add Russian language support](https://github.com/MaincodeHQ/matilda-code/pull/1238).
 
-### Maintaining `zh-TW` (Traditional Chinese for Taiwan)
-
-`zh-TW` is **not** an automatic OpenCC s2t conversion of `zh.js` — it is a hand-maintained Taiwan-vocabulary translation. When adding or updating keys, please follow the conventions below.
-
-The "CI enforced?" column indicates whether `npm run check-i18n` will fail the build on a violation. Rows marked **No** are style guidance enforced by review only — typically because the offending form has a legitimate non-UI meaning (`文件` can mean "document", `打開` is colloquially fine in Taiwan).
-
-| Avoid                 | Use instead           | CI enforced? | Reason                                                                                                                                                                           |
-| --------------------- | --------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| 文件 (file)           | 檔案                  | No           | Taiwan term for filesystem files (but `文件` can legitimately mean "document")                                                                                                   |
-| 服務器 / 服务器       | 伺服器                | Yes          | Taiwan term for "server"                                                                                                                                                         |
-| 菜單 / 菜单           | 選單                  | Yes          | Taiwan term for "menu"                                                                                                                                                           |
-| 鏈接 / 链接           | 連結                  | Yes          | Taiwan term for "link" (bare `鏈` is fine — e.g. 區塊鏈)                                                                                                                         |
-| 打開                  | 開啟                  | No           | Taiwan-preferred verb for "open" (UI); `打開` is colloquially common                                                                                                             |
-| 爲 / 啓 / 曆史 / 鏈接 | 為 / 啟 / 歷史 / 連結 | Yes          | Variant Traditional forms from raw OpenCC s2t. Note: `曆` is context-dependent and correct in calendar terms (日曆, 農曆, 西曆); CI only flags the bigram `曆史`, not bare `曆`. |
-
-If you are not a Traditional Chinese speaker and need to bootstrap a value, **do not paste raw OpenCC `s2t` output**: the default s2t profile emits variant Traditional characters (e.g. 爲, 啓) that Taiwan does not use, and never rewrites Mainland-Chinese vocabulary (服務器, 菜單). Prefer `s2twp.json` (Simplified → Taiwan with phrase mapping) as a starting point and then ask a Taiwan-Chinese speaker to review.
-
-The `check-i18n` script (run in CI via `npm run check-i18n`) will fail the build if any of the CI-enforced substrings above end up in a `zh-TW` value. See `scripts/check-i18n.ts → ZH_TW_FORBIDDEN_PATTERNS` for the full list. If a translation legitimately needs to contain a CI-forbidden substring, add its key to `ZH_TW_ALLOWED_EXCEPTIONS` in the same file with a brief justification.
-
-> [!note]
->
-> The check uses plain substring matching, which does not understand Chinese word boundaries. A bigram pattern can therefore false-positive across compound-word boundaries — for example, `區塊鏈接口` (= `區塊鏈` + `接口`) contains the substring `鏈接` even though neither word is incorrect. If you hit a surprising CI failure of this kind, add the translation key to `ZH_TW_ALLOWED_EXCEPTIONS` rather than removing the pattern.
-
 ### Language Pack Format
 
 ```javascript

package/bundled/mainy/docs/features/sub-agents.md

@@ -189,7 +189,7 @@ tools:
 
 The `fast` selector uses the same `fastModel` setting configured in
 `settings.json` or with `/model --fast`. That setting may itself refer to a
-model under another configured auth type, such as `openai:deepseek-v4-flash`.
+model under another configured auth type, such as `openai:gpt-4o-mini`.
 When the selector resolves to another auth type, Matilda Code creates a dedicated
 runtime provider for that subagent request and sends the provider only the bare
 model ID.

package/bundled/mainy/docs/features/worktree.md

@@ -36,7 +36,7 @@ matilda --resume <session-id> --worktree=my-feature
 
 `process.cwd()` and the model's workspace are switched to the worktree before the first turn runs. Exit with `Ctrl+C` twice and the [Exit Dialog](#exit-dialog-ctrlc--ctrld) prompts to keep or remove the worktree.
 
-The `--worktree` flag cannot be combined with `--acp`/`--experimental-acp` — for ACP hosts (like Zed), pass the worktree path as the `cwd` of the `loadSession`/`newSession` request instead.
+The `--worktree` flag cannot be combined with `--acp`/`--experimental-acp`. For ACP hosts (like the VS Code companion), pass the worktree path as the `cwd` of the `loadSession`/`newSession` request instead.
 
 ### Or ask mid-session
 
@@ -148,7 +148,7 @@ The active worktree binding is persisted to a sidecar file alongside your sessio
 <chatsDir>/<sessionId>.worktree.json
 ```
 
-When you launch the CLI with `--resume <sessionId>` (or pick the session from `/resume`), three things happen consistently across **interactive TUI**, **headless `-p`**, and **ACP/Zed** modes:
+When you launch the CLI with `--resume <sessionId>` (or pick the session from `/resume`), three things happen consistently across **interactive TUI**, **headless `-p`**, and **ACP** modes:
 
 1. The sidecar is loaded and the worktree directory is verified to still exist on disk.
 2. If alive, the model receives a one-shot reminder on its very next prompt:
@@ -163,7 +163,7 @@ Each mode chooses its own injection mechanism, but the user-visible behavior is
 | ----------------- | ------------------------------------------------------------------------------------------------------ |
 | Interactive (TUI) | `INFO` history item + system-reminder prefix on the next user prompt.                                  |
 | Headless (`-p`)   | `<system-reminder>` prefix on the prompt + `worktree_restored` JSON system event in the output stream. |
-| ACP (e.g. Zed)    | Pending notice attached to the next `prompt()` call.                                                   |
+| ACP               | Pending notice attached to the next `prompt()` call.                                                   |
 
 The model is **not** automatically `chdir`'d into the worktree — the reminder is what keeps it routing edits through the worktree path.
 
@@ -328,8 +328,6 @@ The following items are intentionally not implemented in the current phase:
 - **Mid-session `enter_worktree` does NOT switch `process.cwd()` or `Config.targetDir`.** That tool uses the model-context-only convention (see [Sub-Agents](./sub-agents.md)). Only the startup `--worktree` flag actually switches the process working directory.
 - **Relative paths in other arg fields are resolved BEFORE the worktree chdir.** Path-taking flags (`--mcp-config`, `--openai-logging-dir`, `--json-file`, `--input-file`, `--telemetry-outfile`, `--include-directories`) are normalized to absolute paths against the launch cwd when `--worktree` is set. Other path-shaped argv fields not in this list still resolve against the worktree cwd — use absolute paths to be safe.
 
-Track the roadmap in `docs/design/worktree.md`.
-
 ## Troubleshooting
 
 **The Footer shows no worktree indicator even though I just created one.**

package/bundled/mainy/docs/integration-github-action.md

@@ -21,7 +21,7 @@ Get started with Matilda Code CLI in your repository in just a few minutes:
 
 ### 1. Get a Matilda API Key
 
-Obtain your API key from [Matilda-compatible](https://help.matilda.com/zh/model-studio/matilda-code) (Matilda's AI platform)
+Get a Matilda API token from the [Matilda external API guide][Matilda external API].
 
 ### 2. Add it as a GitHub Secret
 
@@ -175,7 +175,7 @@ You can set the following secrets in your repository:
 
 | Name              | Description                                   | Required | When Required                                 |
 | ----------------- | --------------------------------------------- | -------- | --------------------------------------------- |
-| `MATILDA_API_KEY` | Your Matilda API key from Matilda-compatible. | Yes      | Required for all workflows that call Matilda. |
+| `MATILDA_API_KEY` | Your Matilda API token.                       | Yes      | Required for all workflows that call Matilda. |
 | `APP_PRIVATE_KEY` | Private key for your GitHub App (PEM format). | No       | Using a custom GitHub App.                    |
 
 To add a secret:
@@ -234,7 +234,7 @@ Contributions are welcome! Check out the Matilda Code CLI **Contributing Guide**
 
 [secrets]: https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions
 [Matilda Code]: https://github.com/MaincodeHQ/matilda-code
-[Matilda-compatible]: https://matilda.maincode.help/welcome/external-api
+[Matilda external API]: https://matilda.maincode.help/welcome/external-api
 [Matilda Code CLI]: https://github.com/MaincodeHQ/matilda-code-action/
 [variables]: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables#creating-configuration-variables-for-a-repository
 [GitHub CLI]: https://docs.github.com/en/github-cli/github-cli

package/bundled/mainy/docs/matilda-serve.md

@@ -497,7 +497,7 @@ const result = await flow.awaitCompletion({ signal: abortCtrl.signal });
 
 **`--require-auth` and dev convenience.** The device-flow routes use the strict mutation gate (PR 15), which means a token-less loopback default returns `401 token_required`. Locally, the simplest way around this during development is `matilda serve --token=dev-token`; you don't need `--require-auth` unless you're hardening the loopback default.
 
-**Cross-daemon limitation.** `oauth_creds.json` is daemon-shared (`~/.matilda/oauth_creds.json`), so a successful login in daemon A is automatically picked up by daemon B's next token refresh — but daemon B's SDK clients won't receive the `auth_device_flow_authorized` event (events are per-daemon).
+**Cross-daemon limitation.** The account is stored in `~/.matilda/matilda-auth.json`, which every daemon on the machine shares, so a sign-in through daemon A is picked up by daemon B's sessions. Daemon B's SDK clients won't receive the `auth_device_flow_authorized` event, though: events are per-daemon.
 
 **Cross-client take-over.** Two SDK clients on the same daemon that both `POST /workspace/auth/device-flow` for the same provider get the per-provider singleton: the first call starts a fresh IdP request and returns `attached: false`; the second call returns the EXISTING in-flight entry with `attached: true`. The take-over is recorded on the audit trail (under the second client's `X-Matilda-Client-Id`) but does NOT emit a separate event — both clients eventually observe the SAME `auth_device_flow_authorized` once the user finishes the IdP page. If your UI distinguishes "I started this" from "someone else's flow I joined", branch on the `attached` field returned by `start()`.
 

package/bundled/mainy/docs/quickstart.md

@@ -185,8 +185,8 @@ Here are the most important commands for daily use:
 | `/clear`              | Clear terminal screen content                    | `/clear` (shortcut: `Ctrl+L`) |
 | `/theme`              | Change Matilda Code visual theme                 | `/theme`                      |
 | `/language`           | View or change language settings                 | `/language`                   |
-| → `ui [language]`     | Set UI interface language                        | `/language ui zh-CN`          |
-| → `output [language]` | Set LLM output language                          | `/language output Chinese`    |
+| → `ui [language]`     | Set UI interface language                        | `/language ui de-DE`          |
+| → `output [language]` | Set LLM output language                          | `/language output German`     |
 | `/quit`               | Exit Matilda Code immediately                    | `/quit` or `/exit`            |
 
 See the [CLI reference](./features/commands) for a complete list of commands.

package/bundled/mainy/docs/support/troubleshooting.md

@@ -9,22 +9,15 @@ This guide provides solutions to common issues and debugging tips, including top
 
 ## Authentication or login errors
 
-- **Error: `Matilda OAuth free tier was discontinued on 2026-04-15`**
-  - **Cause:** Matilda OAuth is no longer available as of April 15, 2026.
-  - **Solution:** Switch to a different authentication method. Run `matilda` → `/auth` and choose one of:
+- **Error: `Invalid auth method selected.`**
+  - **Cause:** `security.auth.selectedType` in `settings.json` names an auth type Matilda Code no longer supports, such as the retired `matilda-oauth`.
+  - **Solution:** Run `matilda auth login`, or `/auth` in an interactive session, and sign in with your Matilda account.
 
 - **Error: `UNABLE_TO_GET_ISSUER_CERT_LOCALLY`, `UNABLE_TO_VERIFY_LEAF_SIGNATURE`, or `unable to get local issuer certificate`**
   - **Cause:** You may be on a corporate network with a firewall that intercepts and inspects SSL/TLS traffic. This often requires a custom root CA certificate to be trusted by Node.js.
   - **Solution:** Set the `NODE_EXTRA_CA_CERTS` environment variable to the absolute path of your corporate root CA certificate file.
     - Example: `export NODE_EXTRA_CA_CERTS=/path/to/your/corporate-ca.crt`
 
-- **Error: `Device authorization flow failed: fetch failed`**
-  - **Cause:** Node.js could not reach Matilda OAuth endpoints (often a proxy or SSL/TLS trust issue). When available, Matilda Code will also print the underlying error cause (for example: `UNABLE_TO_VERIFY_LEAF_SIGNATURE`). Note: this error is specific to the legacy Matilda OAuth flow.
-  - **Solution:**
-    - If you are still using Matilda OAuth, switch to API Key or Coding Plan via `/auth`.
-    - If you are behind a proxy, set it via `matilda --proxy <url>` (or the `proxy` setting in `settings.json`).
-    - If your network uses a corporate TLS inspection CA, set `NODE_EXTRA_CA_CERTS` as described above.
-
 - **Issue: Unable to display UI after authentication failure**
   - **Cause:** If authentication fails after selecting an authentication type, the `security.auth.selectedType` setting may be persisted in `settings.json`. On restart, the CLI may get stuck trying to authenticate with the failed auth type and fail to display the UI.
   - **Solution:** Clear the `security.auth.selectedType` configuration item in your `settings.json` file:

package/chunks/agent-4FTU3WN6.js

@@ -0,0 +1,3 @@
+// Force strict mode and setup for ESM
+"use strict";
+import{Fg as a,Gg as b,Hg as c,Ig as d,Jg as e,Kg as f}from"./chunk-SY6JRCN3.js";import"./chunk-M53RP3YP.js";import"./chunk-FCGYRGV4.js";import"./chunk-G4YMVWG4.js";import"./chunk-5YT4GCK7.js";import"./chunk-MTMU7JYZ.js";import"./chunk-TXMXCR7D.js";import"./chunk-YULUB745.js";import"./chunk-PYZNGIIR.js";import"./chunk-QJJTUDDA.js";import"./chunk-5NMK4Y7C.js";import"./chunk-47XR7IMP.js";import"./chunk-UVWZ44ZW.js";import"./chunk-QKYGQLWC.js";import"./chunk-LHDCAN7Z.js";import"./chunk-V6UPUMP3.js";import"./chunk-RNKDFE2S.js";import"./chunk-VLDZBRTL.js";import"./chunk-RYHMPK5G.js";import"./chunk-JIKQI4MZ.js";import"./chunk-RK4LPGBV.js";import"./chunk-75KP2FVD.js";import"./chunk-7ZODGQO6.js";import"./chunk-TISQNFB5.js";import"./chunk-IIQ5YERM.js";import"./chunk-DC7LAFZZ.js";import"./chunk-LZDHANXA.js";import"./chunk-U7V7APDV.js";import"./chunk-SR7ARGUY.js";import"./chunk-OEZS5R3S.js";import"./chunk-NOE4UNQN.js";import"./chunk-R34HYLL4.js";import"./chunk-EXNHJQCD.js";import"./chunk-2ONZZ46N.js";import"./chunk-62AFAL4I.js";import"./chunk-36K4HBVM.js";import"./chunk-FWDMPRKU.js";import"./chunk-GZPNIYVZ.js";import"./chunk-OWGSC52X.js";export{f as AgentTool,b as TOOL_REGISTRY_REBUILT,e as createApprovalModeOverride,c as hasRebuiltToolRegistry,d as rebuildToolRegistryOnOverride,a as resolveSubagentApprovalMode};

package/chunks/agent-headless-QJUVHPFC.js

@@ -0,0 +1,3 @@
+// Force strict mode and setup for ESM
+"use strict";
+import{dg as a,eg as b,fg as c}from"./chunk-SY6JRCN3.js";import"./chunk-M53RP3YP.js";import"./chunk-FCGYRGV4.js";import"./chunk-G4YMVWG4.js";import"./chunk-5YT4GCK7.js";import"./chunk-MTMU7JYZ.js";import"./chunk-TXMXCR7D.js";import"./chunk-YULUB745.js";import"./chunk-PYZNGIIR.js";import"./chunk-QJJTUDDA.js";import"./chunk-5NMK4Y7C.js";import"./chunk-47XR7IMP.js";import"./chunk-UVWZ44ZW.js";import"./chunk-QKYGQLWC.js";import"./chunk-LHDCAN7Z.js";import"./chunk-V6UPUMP3.js";import"./chunk-RNKDFE2S.js";import"./chunk-VLDZBRTL.js";import"./chunk-RYHMPK5G.js";import"./chunk-JIKQI4MZ.js";import"./chunk-RK4LPGBV.js";import"./chunk-75KP2FVD.js";import"./chunk-7ZODGQO6.js";import"./chunk-TISQNFB5.js";import"./chunk-IIQ5YERM.js";import"./chunk-DC7LAFZZ.js";import"./chunk-LZDHANXA.js";import"./chunk-U7V7APDV.js";import"./chunk-SR7ARGUY.js";import"./chunk-OEZS5R3S.js";import"./chunk-NOE4UNQN.js";import"./chunk-R34HYLL4.js";import"./chunk-EXNHJQCD.js";import"./chunk-2ONZZ46N.js";import"./chunk-62AFAL4I.js";import"./chunk-36K4HBVM.js";import"./chunk-FWDMPRKU.js";import"./chunk-GZPNIYVZ.js";import"./chunk-OWGSC52X.js";export{c as AgentHeadless,a as ContextState,b as templateString};

package/chunks/{askUserQuestion-2QI4NSFJ.js → askUserQuestion-QKX4NEFX.js}

@@ -1,6 +1,6 @@
 // Force strict mode and setup for ESM
 "use strict";
-import{a as r}from"./chunk-ILBTI4K5.js";import"./chunk-47XR7IMP.js";import{g as m,i as h,p as f,q as g}from"./chunk-6E766NPX.js";import{ba as d}from"./chunk-27Q5KW3A.js";import"./chunk-FWDMPRKU.js";import{b as p}from"./chunk-GZPNIYVZ.js";import"./chunk-OWGSC52X.js";p();var a=d("ASK_USER_QUESTION"),b=`Use this tool when you need to ask the user questions during execution. This allows you to:
+import{a as r}from"./chunk-ILBTI4K5.js";import"./chunk-47XR7IMP.js";import{g as m,i as h,p as f,q as g}from"./chunk-2ONZZ46N.js";import{ba as d}from"./chunk-62AFAL4I.js";import"./chunk-FWDMPRKU.js";import{b as p}from"./chunk-GZPNIYVZ.js";import"./chunk-OWGSC52X.js";p();var a=d("ASK_USER_QUESTION"),b=`Use this tool when you need to ask the user questions during execution. This allows you to:
 1. Gather user preferences or requirements
 2. Clarify ambiguous instructions
 3. Get decisions on implementation choices as you work