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

package/bundled/mainy/docs/configuration/trusted-folders.md

@@ -1,18 +1,18 @@
 # Trusted Folders
 
-The Trusted Folders feature is a security setting that gives you control over which projects can use the full capabilities of the Matilda Code. It prevents potentially malicious code from running by asking you to approve a folder before the CLI loads any project-specific configurations from it.
+The Trusted Folders feature is a security setting that gives you control over which projects can use the full capabilities of the Matilda Code. It asks you to approve a folder before the CLI admits its workspace settings and project hooks.
 
-## Enabling the Feature
+## Default Policy
 
-The Trusted Folders feature is **disabled by default**. To use it, you must first enable it in your settings.
+Folder trust is **enabled by default** for interactive CLI sessions. An unknown folder uses the existing trust dialog before its workspace settings and project hooks are admitted.
 
-Add the following to your user `settings.json` file:
+To disable folder trust explicitly, add the following to your user `settings.json` file:
 
 ```json
 {
   "security": {
     "folderTrust": {
-      "enabled": true
+      "enabled": false
     }
   }
 }
@@ -28,13 +28,15 @@ Once the feature is enabled, the first time you run the Matilda Code from a fold
 
 Your choice is saved in a central file (`~/.matilda/trustedFolders.json`), so you will only be asked once per folder.
 
+Explicit headless requests, including `-p` and piped input, retain implicit consent for unknown folders. Desktop uses its approved workspace and additional-directory manifest. These runtime decisions do not rewrite saved trust rules, and explicit rejections still apply. Generic ACP requests do not receive blanket consent.
+
 ## Why Trust Matters: The Impact of an Untrusted Workspace
 
 When a folder is **untrusted**, the Matilda Code runs in a restricted "safe mode" to protect you. In this mode, the following features are disabled:
 
 1.  **Workspace Settings are Ignored**: The CLI will **not** load the `.matilda/settings.json` file from the project. This prevents the loading of custom tools and other potentially dangerous configurations.
 
-2.  **Environment Variables are Ignored**: The CLI will **not** load any `.env` files from the project.
+2.  **Project Environment Files Need Trust**: Unknown and rejected folders do not load project `.env` files. User-level environment files remain available.
 
 3.  **Extension Management is Restricted**: You **cannot install, update, or uninstall** extensions.
 
@@ -44,6 +46,8 @@ When a folder is **untrusted**, the Matilda Code runs in a restricted "safe mode
 
 Granting trust to a folder unlocks the full functionality of the Matilda Code for that workspace.
 
+Even in trusted folders, project `.env`, `.matilda/.env` and workspace `settings.env` cannot change process bootstrap or policy variables, including `NODE_OPTIONS`, `NODE_PATH`, `BASH_ENV`, `LD_PRELOAD`, `PATH`, storage locations, trust-file locations and Desktop directory consent. Ordinary variables, including gateway `*_BASE_URL` values, remain available. User-level files keep their initial loading behavior.
+
 ## Managing Your Trust Settings
 
 If you need to change a decision or see all your settings, you have a couple of options:
@@ -59,3 +63,5 @@ For advanced users, it's helpful to know the exact order of operations for how t
 1.  **IDE Trust Signal**: If you are using the [IDE Integration](../ide-integration/ide-integration), the CLI first asks the IDE if the workspace is trusted. The IDE's response takes highest priority.
 
 2.  **Local Trust File**: If the IDE is not connected, the CLI checks the central `~/.matilda/trustedFolders.json` file.
+
+3.  **Runtime Consent**: If no saved decision exists, explicit headless use or Desktop's approved-directory manifest can grant trust for that runtime. Other unknown folders remain unresolved until the interactive choice.

package/bundled/mainy/docs/features/auto-mode.md

@@ -173,7 +173,7 @@ ask you for explicit approval rather than route around the denial.
 
 Classifier reasons are produced by the LLM and are not translated. If you
 want non-English reasons, add a hint like
-`Respond reasons in Chinese` to `permissions.autoMode.environment`.
+`Respond reasons in Japanese` to `permissions.autoMode.environment`.
 
 ## Fallback to manual approval
 

package/bundled/mainy/docs/features/channels/_meta.ts

@@ -1,8 +1,5 @@
 export default {
   overview: 'Overview',
   telegram: 'Telegram',
-  weixin: 'WeChat',
-  dingtalk: 'DingTalk',
-  feishu: 'Feishu',
   plugins: 'Plugins',
 };

package/bundled/mainy/docs/features/channels/overview.md

@@ -1,6 +1,6 @@
 # Channels
 
-Channels let you interact with a Matilda Code agent from messaging platforms like Telegram, WeChat, or DingTalk, instead of the terminal. You send messages from your phone or desktop chat app, and the agent responds just like it would in the CLI.
+Channels let you interact with a Matilda Code agent from messaging platforms like Telegram, instead of the terminal. You send messages from your phone or desktop chat app, and the agent responds just like it would in the CLI.
 
 ## How It Works
 
@@ -15,7 +15,7 @@ All channels share one agent process with isolated sessions per user. Each chann
 
 ## Quick Start
 
-1. Set up a bot on your messaging platform (see channel-specific guides: [Telegram](./telegram), [WeChat](./weixin), [DingTalk](./dingtalk))
+1. Set up a bot on your messaging platform (see the [Telegram](./telegram) guide)
 2. Add the channel configuration to `~/.matilda/settings.json`
 3. Run `matilda channel start` to start all channels, or `matilda channel start <name>` for a single channel
 
@@ -49,10 +49,10 @@ Channels are configured under the `channels` key in `settings.json`. Each channe
 
 | Option                   | Required | Description                                                                                                                                    |
 | ------------------------ | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
-| `type`                   | Yes      | Channel type: `telegram`, `weixin`, `dingtalk`, or a custom type from an extension (see [Plugins](./plugins))                                  |
-| `token`                  | Telegram | Bot token. Supports `$ENV_VAR` syntax to read from environment variables. Not needed for WeChat or DingTalk                                    |
-| `clientId`               | DingTalk | DingTalk AppKey. Supports `$ENV_VAR` syntax                                                                                                    |
-| `clientSecret`           | DingTalk | DingTalk AppSecret. Supports `$ENV_VAR` syntax                                                                                                 |
+| `type`                   | Yes      | Channel type: `telegram`, or a custom type from an extension (see [Plugins](./plugins))                                                        |
+| `token`                  | Telegram | Bot token. Supports `$ENV_VAR` syntax to read from environment variables                                                                       |
+| `clientId`               | No       | Client ID, for extension channels that need one. Supports `$ENV_VAR` syntax                                                                    |
+| `clientSecret`           | No       | Client secret, for extension channels that need one. Supports `$ENV_VAR` syntax                                                                |
 | `model`                  | No       | Model to use for this channel (e.g., `matilda3.5-plus`). Overrides the default model. Useful for multimodal models that support image input    |
 | `senderPolicy`           | No       | Who can talk to the bot: `allowlist` (default), `open`, or `pairing`                                                                           |
 | `allowedUsers`           | No       | List of user IDs allowed to use the bot (used by `allowlist` and `pairing` policies)                                                           |
@@ -215,14 +215,6 @@ Send a document (PDF, code file, text file, etc.) to the bot. The file is downlo
 
 Files work with any model — no multimodal support required.
 
-### Platform differences
-
-| Feature  | Telegram                                     | WeChat                           | DingTalk                                      |
-| -------- | -------------------------------------------- | -------------------------------- | --------------------------------------------- |
-| Images   | Direct download via Bot API                  | CDN download with AES decryption | downloadCode API (two-step)                   |
-| Files    | Direct download via Bot API (20MB limit)     | CDN download with AES decryption | downloadCode API (two-step)                   |
-| Captions | Photo/file captions included as message text | Not applicable                   | Rich text: mixed text + images in one message |
-
 ## Dispatch Modes
 
 Controls what happens when you send a new message while the bot is still processing a previous one.
@@ -292,7 +284,7 @@ Channels support slash commands. These are handled locally (no agent round-trip)
 
 All other slash commands (e.g., `/compress`, `/summary`) are forwarded to the agent.
 
-These commands work on all channel types (Telegram, WeChat, DingTalk).
+These commands work on all channel types.
 
 ## Running
 
@@ -314,7 +306,7 @@ The bot runs in the foreground. Press `Ctrl+C` to stop, or use `matilda channel
 
 ### Multi-Channel Mode
 
-When you run `matilda channel start` without a name, all channels defined in `settings.json` start together sharing a single agent process. Each channel maintains its own sessions — a Telegram user and a WeChat user get separate conversations, even though they share the same agent.
+When you run `matilda channel start` without a name, all channels defined in `settings.json` start together sharing a single agent process. Each channel maintains its own sessions, so users on different channels get separate conversations, even though they share the same agent.
 
 Each channel uses its own `cwd` from its config, so different channels can work on different projects simultaneously.
 

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

@@ -59,11 +59,11 @@ Commands specifically for controlling interface and output language.
 | Command               | Description                      | Usage Examples             |
 | --------------------- | -------------------------------- | -------------------------- |
 | `/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 English` |
 
-- Available built-in UI languages: `zh-CN` (Simplified Chinese), `en-US` (English), `ru-RU` (Russian), `de-DE` (German), `ja-JP` (Japanese), `pt-BR` (Portuguese - Brazil), `fr-FR` (French), `ca-ES` (Catalan)
-- Output language examples: `Chinese`, `English`, `Japanese`, etc.
+- Available built-in UI languages: `en-US` (English), `ru-RU` (Russian), `de-DE` (German), `ja-JP` (Japanese), `pt-BR` (Portuguese - Brazil), `fr-FR` (French), `ca-ES` (Catalan)
+- Output language examples: `English`, `Japanese`, `German`, etc.
 
 ### 1.4 Tool and Model Management
 

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-XWHJY3DM.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-T4P4KEDW.js";import{ba as d}from"./chunk-MH2P4YXC.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