@f5-sales-demo/xcsh 21.33.14 → 21.34.0

package/package.json

@@ -1,7 +1,7 @@
 {
 	"type": "module",
 	"name": "@f5-sales-demo/xcsh",
-	"version": "21.33.14",
+	"version": "21.34.0",
 	"description": "Coding agent CLI with read, bash, edit, write tools and session management",
 	"homepage": "https://github.com/f5-sales-demo/xcsh",
 	"author": "Can Boluk",
@@ -63,13 +63,13 @@
 	},
 	"dependencies": {
 		"@agentclientprotocol/sdk": "1.4.0",
-		"@f5-sales-demo/pi-agent-core": "21.33.14",
-		"@f5-sales-demo/pi-ai": "21.33.14",
-		"@f5-sales-demo/pi-natives": "21.33.14",
-		"@f5-sales-demo/pi-resource-management": "21.33.14",
-		"@f5-sales-demo/pi-tui": "21.33.14",
-		"@f5-sales-demo/pi-utils": "21.33.14",
-		"@f5-sales-demo/xcsh-stats": "21.33.14",
+		"@f5-sales-demo/pi-agent-core": "21.34.0",
+		"@f5-sales-demo/pi-ai": "21.34.0",
+		"@f5-sales-demo/pi-natives": "21.34.0",
+		"@f5-sales-demo/pi-resource-management": "21.34.0",
+		"@f5-sales-demo/pi-tui": "21.34.0",
+		"@f5-sales-demo/pi-utils": "21.34.0",
+		"@f5-sales-demo/xcsh-stats": "21.34.0",
 		"@mozilla/readability": "^0.6",
 		"@sinclair/typebox": "0.34.52",
 		"@xterm/headless": "^6.0",

package/src/config/auto-config.ts

@@ -20,7 +20,7 @@ import { hardenAgentConfigFileSync, writeAgentConfigFileSync } from "./agent-con
 import { DEFAULT_MODEL_ROLE } from "./settings-schema";
 
 /** Current config schema version. Bump when the generated format changes. */
-export const CURRENT_CONFIG_VERSION = 6;
+export const CURRENT_CONFIG_VERSION = 7;
 const LITELLM_CONFIG_DIR_MODE = 0o700;
 const LITELLM_MODELS_FILE_MODE = 0o600;
 const GENERATED_LITELLM_MARKER = "# Auto-generated by xcsh for LiteLLM proxy";
@@ -92,14 +92,36 @@ export function generateModelsYml(baseUrl: string, options?: GenerateModelsYmlOp
 		"    discovery:",
 		"      type: openai-compat",
 		"    modelAllowlist:",
+		"      - gpt-6-astra",
 		"      - gpt-5.6-sol",
 		"      - gpt-5.6-terra",
 		"      - gpt-5.6-luna",
+		"    models:",
+		"      - id: gpt-6-astra",
+		"        name: GPT-6 Astra",
 		"    picker:",
 		"      groupId: litellm",
 		"      groupLabel: LiteLLM",
 		"      sectionLabel: OpenAI",
 		"    modelOverrides:",
+		"      gpt-6-astra:",
+		"        reasoning: true",
+		"        input:",
+		"          - text",
+		"          - image",
+		"        thinking:",
+		"          mode: effort",
+		"          defaultLevel: medium",
+		"          supportedLevels:",
+		"            - { effort: low, description: Light reasoning }",
+		"            - { effort: medium, description: Balanced reasoning }",
+		"            - { effort: high, description: Deep reasoning }",
+		"            - { effort: xhigh, description: Very deep reasoning }",
+		"            - { effort: max, description: Maximum reasoning }",
+		"        contextWindow: 1050000",
+		"        maxTokens: 128000",
+		"        compat:",
+		"          supportsTemperature: false",
 		"      gpt-5.6-sol:",
 		"        reasoning: true",
 		"        input:",

package/src/internal-urls/build-info.generated.ts

@@ -17,17 +17,17 @@ export interface BuildInfo {
 }
 
 export const BUILD_INFO: BuildInfo = {
-	"version": "21.33.14",
-	"commit": "388cb2dbc104c237f72bb0b244228ab42ff532b4",
-	"shortCommit": "388cb2d",
+	"version": "21.34.0",
+	"commit": "530c96b9ab12b289ae046fd34b9fe785ddf12e5d",
+	"shortCommit": "530c96b",
 	"branch": "main",
-	"tag": "v21.33.14",
-	"commitDate": "2026-09-19T19:32:03+00:00",
-	"buildDate": "2026-09-19T20:29:39.230Z",
+	"tag": "v21.34.0",
+	"commitDate": "2026-09-20T11:29:42+00:00",
+	"buildDate": "2026-09-20T12:28:13.673Z",
 	"dirty": true,
 	"prNumber": "",
 	"repoUrl": "https://github.com/f5-sales-demo/xcsh",
 	"repoSlug": "f5-sales-demo/xcsh",
-	"commitUrl": "https://github.com/f5-sales-demo/xcsh/commit/388cb2dbc104c237f72bb0b244228ab42ff532b4",
-	"releaseUrl": "https://github.com/f5-sales-demo/xcsh/releases/tag/v21.33.14"
+	"commitUrl": "https://github.com/f5-sales-demo/xcsh/commit/530c96b9ab12b289ae046fd34b9fe785ddf12e5d",
+	"releaseUrl": "https://github.com/f5-sales-demo/xcsh/releases/tag/v21.34.0"
 };

package/src/internal-urls/docs-index.generated.ts

@@ -28,7 +28,7 @@ export const EMBEDDED_DOCS: Readonly<Record<string, string>> = {
 	"en/automate-extend/skills.mdx": "---\ntitle: \"Create and load skills\"\ndescription: \"Package task-specific instructions in `SKILL.md` files at user or project scope.\"\nsidebar:\n  order: 5\n  label: \"Create and load skills\"\n---\n\nA skill is a directory centered on `SKILL.md`. It tells an agent when and how to perform a bounded kind of work; it is not executable proof by itself.\n\n## Where do skills live?\n\nUse project scope under `.xcsh/skills/` for repository-specific instructions and user scope under the xcsh data directory for personal skills. Project instructions should be reviewable with the repository.\n\n## How do I test one?\n\nStart xcsh with `--skills <GLOB>` to narrow discovery, invoke a prompt that matches the trigger, and inspect the tools and output. Use `--no-skills` to confirm behavior without it.\n\nGive `SKILL.md` a narrow trigger, explicit prerequisites, ordered actions, and a verifiable stopping\ncondition. Keep executable helpers inside the skill directory and invoke them through their\ndocumented interface rather than embedding machine-specific paths. Test positive and negative\nprompts with only that skill selected, inspect which instructions were loaded, then remove the\ntemporary skill and confirm the trigger no longer matches.\n",
 	"en/configure-secure/environment-reference.mdx": "---\ntitle: \"Environment variable reference\"\ndescription: \"Look up the environment variables that select models, credentials, tenants, execution behavior, storage roots, and diagnostics.\"\nsidebar:\n  order: 2\n  label: \"Environment variables\"\n---\n\nEnvironment variables carry credentials and process-scoped overrides. Settings files and command flags keep their documented precedence; a similarly named variable is not automatically supported. Provider adapters read their own vendor key names, which the adapter defines rather than this list.\n\n## Which variables configure models, providers, and search?\n\n| Variable | Controls |\n| --- | --- |\n| `PI_SMOL_MODEL` | Default model for the lightweight role, equivalent to `--smol` |\n| `PI_SLOW_MODEL` | Default model for the reasoning role, equivalent to `--slow` |\n| `PI_PLAN_MODEL` | Default model for the planning role, equivalent to `--plan` |\n| `XCSH_LOCALE` | Interface locale, ahead of `PI_LOCALE` and `LANG` |\n\nA flag beats the variable: `--smol` overrides `PI_SMOL_MODEL` for that invocation. Model selection stays a model-registry decision, so a name these variables set must still resolve through `xcsh --list-models <PROVIDER>`.\n\n## Which variables address an F5 Distributed Cloud tenant?\n\n| Variable | Controls |\n| --- | --- |\n| `XCSH_API_URL` | Tenant application programming interface (API) endpoint when no named context is active |\n| `XCSH_API_TOKEN` | Tenant API credential for that endpoint |\n| `XCSH_TENANT` | Tenant identifier reported in context status |\n| `XCSH_CONTEXT_NAME` | Name of the context the session binds to |\n| `XCSH_NAMESPACE` | Namespace applied when a command does not pass `-n` |\n| `F5XC_NAMESPACE` | Namespace source recorded in resource operation records |\n\nTreat every value in this group as a secret. Supply them through the runtime environment or a named context, never through a committed file or a command argument that reaches shell history.\n\n## Which variables configure Python, shell, and tool execution?\n\n| Variable | Controls |\n| --- | --- |\n| `PI_PYTHON_GATEWAY_URL` | Endpoint the Python tool sends code to |\n| `PI_PYTHON_GATEWAY_TOKEN` | Credential for that gateway |\n| `PI_PYTHON_SKIP_CHECK` | Skips the gateway warm-up probe |\n| `PI_SHELL_PREFIX` | Command prefix wrapped around shell tool invocations |\n| `PI_BASH_NO_LOGIN` | Runs the shell without `-l` |\n| `PI_NO_PTY` | Disables pseudo-terminal (PTY) execution, equivalent to `--no-pty` |\n| `PI_EDIT_VARIANT` | Selects the edit tool implementation and rejects an unknown value |\n\nShell execution inherits the launched process environment, subject to the sandbox and command policy. Restrict dependencies, working directory, and credentials at the process boundary rather than in the prompt.\n\n## Which variables configure storage, runtime, and diagnostics?\n\n| Variable | Controls |\n| --- | --- |\n| `PI_CODING_AGENT_DIR` | Primary agent data root, including session storage |\n| `PI_CONFIG_DIR` | Configuration root directory name, `.xcsh` by default |\n| `PI_PACKAGE_DIR` | Packaged asset directory the runtime resolves against |\n| `PI_SESSION_FILE` | Session file a child process attaches to |\n| `PI_NATIVE_VARIANT` | Hardware variant the native addon loader prefers |\n| `PI_CACHE_RETENTION` | Cache retention policy, `short` by default |\n| `PI_NO_TITLE` | Disables title auto-generation, equivalent to `--no-title` |\n| `PI_NOTIFICATIONS` | Desktop notification behavior |\n| `PI_DEBUG_STARTUP` | Startup phase diagnostics |\n| `PI_TIMING` | Phase timing output |\n| `PI_TUI_DEBUG` | Terminal user interface (TUI) rendering diagnostics |\n\nProject configuration stays under `.xcsh/` even when `PI_CODING_AGENT_DIR` moves the user root. Never print a credential-bearing variable into a diagnostic receipt; name the variable and state whether it was set.\n\nSet a variable only in the process that needs it, then use the relevant read-only command or a\nno-tool prompt to confirm selection. Environment values can override files and may be inherited by\nsubprocesses; never print tokens while diagnosing precedence. To undo a test, unset the variable in\nthe same shell and start a new xcsh process because an existing process has already captured its\nenvironment.\n",
 	"en/configure-secure/index.mdx": "---\ntitle: \"Configure and secure\"\ndescription: \"Control settings, providers, credentials, networking, secrets, sandboxing, and runtime boundaries.\"\nsidebar:\n  order: 0\n  label: \"Overview\"\n---\n\nConfiguration controls provider routing, settings precedence, filesystem access, and credential handling.\n\n## What should I configure first?\n\n1. Inspect [settings precedence and file locations](/xcsh/en/configure-secure/settings-files/).\n2. Look up any [environment variable](/xcsh/en/configure-secure/environment-reference/) the deployment sets.\n3. Choose a [provider and model route](/xcsh/en/configure-secure/providers-routing/).\n4. Apply [secret handling and the filesystem boundary](/xcsh/en/configure-secure/secrets-obfuscation/).\n5. Set the [sandbox boundaries](/xcsh/en/configure-secure/sandbox-boundaries/) that enforce those decisions.\n\nStart with defaults; add project configuration only when collaborators need the same behavior.\n",
-	"en/configure-secure/providers-routing.mdx": "---\ntitle: \"Configure providers and model routing\"\ndescription: \"Select models directly or map default, smol, slow, and plan roles.\"\nsidebar:\n  order: 3\n  label: \"Providers and models\"\nhead:\n  - tag: style\n    content: |\n      .sl-markdown-content .expressive-code { max-width: 100%; overflow-x: auto; }\n      .sl-markdown-content table { display: block; max-width: 100%; overflow-x: auto; }\n---\n\nxcsh resolves a requested model against available providers and credentials. A provider-qualified model name is the most explicit route.\n\n## How do I confirm a route?\n\nRun `xcsh --list-models <PROVIDER>`, then pass one returned name to `--model`. Environment keys and supported subscription sessions authenticate providers; never store tokens in committed settings.\n\n## How do I select a model in a conversation?\n\nOpen `/model`. Tab and Shift+Tab browse providers; typing searches across them. The active conversation model and saved role badges are shown separately. Configured providers remain visible when discovery is empty, unavailable, or requires authentication. Use Ctrl+R to refresh the current provider or Ctrl+L to open login.\n\nChoose a model with Enter, then choose its scope:\n\n- **Use in this conversation** is preselected. It changes this session, including resume, without changing saved role assignments.\n- **Save as default** changes the current conversation and the default for future sessions.\n- **Assign to role** saves Default, Fast/SMOL, Thorough/SLOW, Plan, or another existing role. Roles other than Default leave the current conversation unchanged.\n\nChoose a reasoning level supported by that exact model and press Enter to confirm. Inherit displays the provider default; an existing supported reasoning selection is preselected. Escape backs out without applying an unfinished choice. Failed writes are reported before badges show success.\n\nClaude Fable 5 and 5.1 use adaptive thinking on every request. Their default is `high`; supported\nchoices are `low`, `medium`, `high`, `xhigh`, and `max`, with xcsh's `minimal` choice mapped to\nAnthropic `low`. `off` is rejected because the Fable API does not support disabling thinking.\nFable also does not accept temperature or forced tool selection, so xcsh omits temperature and\nnormalizes `any` or a named forced tool to `auto` while retaining strict tool schemas.\n\nWhen the authenticated ChatGPT subscription catalog includes GPT-6 Astra, `/model` presents it as an additional premium option under **ChatGPT Subscription**. Astra does not replace the existing Luna, Terra, Sol, or role assignments unless you explicitly assign it.\n\nA manual conversation choice remains in effect under automatic routing. Entering planning mode uses the Plan assignment; exiting restores the prior conversation model and reasoning. Explicit `--models` scopes still limit the picker.\n\nOpen `/login` to see providers that are configured, credential-backed, allowlisted, active, or freshly detected. Optional local runtimes do not appear merely because xcsh attempted an automatic probe. Choose `Add provider…` to search the complete built-in catalog.\n\nProvider rows use human status labels. Press Right on a row to inspect its credential source, last verification, sanitized failure reason, model visibility, and any grouped routes. `/logout` lists only providers with stored credentials that xcsh can remove; environment and configuration credentials are not presented as removable.\n\nProvider grouping in `models.yml` is also used by the management view:\n\n```yaml\nproviders:\n  litellm:\n    picker:\n      groupId: litellm\n      groupLabel: LiteLLM\n      sectionLabel: OpenAI\n    modelAllowlist:\n      - gpt-5.6-sol\n      - gpt-5.6-terra\n      - gpt-5.6-luna\n  anthropic:\n    picker:\n      groupId: litellm\n      groupLabel: LiteLLM\n      sectionLabel: Anthropic\n    modelAllowlist:\n      - claude-fable-5-1\n      - claude-fable-5\n      - claude-opus-5\n      - claude-sonnet-5\n      - claude-haiku-4-5\n```\n\n`modelProviderAllowlist` is a settings key that limits normal `/model` visibility. An empty list means no picker restriction; it does not make every built-in provider relevant in `/login`. Explicit provider-qualified command-line selection and direct `/login <provider>` remain available.\n\n```bash\nxcsh config set modelProviderAllowlist '[\"litellm\", \"anthropic\"]'\nxcsh config set modelProviderOrder '[\"litellm\", \"anthropic\", \"google-vertex\"]'\n```\n\nFor command-line selection, qualify the provider whenever several usable providers expose the same model ID. A bare `--model` value succeeds only when one usable provider matches; otherwise xcsh prints the qualified choices and exits nonzero in noninteractive mode.\n\nThe two explicit Fable aliases are an exception to general fuzzy selection:\n\n```bash\nxcsh --model fable\nxcsh --model anthropic/fable\n```\n\nBoth select `anthropic/claude-fable-5-1` deterministically.\n\n## Where does LiteLLM fit?\n\nLiteLLM is an optional provider proxy installed or checked with `xcsh setup litellm`. Its base uniform resource locator (URL) and credential belong in the runtime environment. Successful text Responses support does not imply Realtime or audio support; test the exact endpoint your workflow uses.\n\n## How do I test licensed Vertex locally?\n\n`bun run dev` and local coding-agent binary builds load the licensed Vertex OAuth client pair automatically. Explicit `XCSH_VERTEX_OAUTH_CLIENT_ID` and `XCSH_VERTEX_OAUTH_CLIENT_SECRET` build inputs take precedence; supply both together.\n\nFor local UAT, the first launch can recover the embedded client pair from an installed official xcsh binary\nand retain it in `$XDG_CONFIG_HOME/xcsh/vertex-build.json` (default `~/.config/xcsh/vertex-build.json`). The\nfile is outside the checkout, shared by local sessions and worktrees for the same operating-system user, and\ncreated with owner-only permissions. Each worktree needs this development/build launcher to load it\nautomatically. Later launches reuse it even if the installed binary changes.\n`XCSH_VERTEX_OAUTH_CREDENTIALS_FILE` selects another private local file containing `clientId` and\n`clientSecret` fields.\n\nThe source-runtime preload keeps the pair in process memory; local compiled candidates embed it. Do not copy\nthis file or its values into source control, logs, or UAT reports. CI does not read or recover workstation\ncredentials: official release builds continue to receive the pair through GitHub secrets. Unit tests use\nfixture credentials; the live provider smoke script uses the same local preload as development UAT.\n\nRoute selection is complete only when the provider, account, and model all match the intended\nboundary. Use `/model` in the TUI or the explicit model flag shown by `xcsh --help`, send a no-tool\nidentity prompt, and inspect the session metadata. Switching a model affects subsequent turns; it\ndoes not rewrite earlier entries. Remove temporary route overrides and start a new session to verify\nthe default path independently.\n",
+	"en/configure-secure/providers-routing.mdx": "---\ntitle: \"Configure providers and model routing\"\ndescription: \"Select models directly or map default, smol, slow, and plan roles.\"\nsidebar:\n  order: 3\n  label: \"Providers and models\"\nhead:\n  - tag: style\n    content: |\n      .sl-markdown-content .expressive-code { max-width: 100%; overflow-x: auto; }\n      .sl-markdown-content table { display: block; max-width: 100%; overflow-x: auto; }\n---\n\nxcsh resolves a requested model against available providers and credentials. A provider-qualified model name is the most explicit route.\n\n## How do I confirm a route?\n\nRun `xcsh --list-models <PROVIDER>`, then pass one returned name to `--model`. Environment keys and supported subscription sessions authenticate providers; never store tokens in committed settings.\n\n## How do I select a model in a conversation?\n\nOpen `/model`. Tab and Shift+Tab browse providers; typing searches across them. The active conversation model and saved role badges are shown separately. Configured providers remain visible when discovery is empty, unavailable, or requires authentication. Use Ctrl+R to refresh the current provider or Ctrl+L to open login.\n\nChoose a model with Enter, then choose its scope:\n\n- **Use in this conversation** is preselected. It changes this session, including resume, without changing saved role assignments.\n- **Save as default** changes the current conversation and the default for future sessions.\n- **Assign to role** saves Default, Fast/SMOL, Thorough/SLOW, Plan, or another existing role. Roles other than Default leave the current conversation unchanged.\n\nChoose a reasoning level supported by that exact model and press Enter to confirm. Inherit displays the provider default; an existing supported reasoning selection is preselected. Escape backs out without applying an unfinished choice. Failed writes are reported before badges show success.\n\nClaude Fable 5 and 5.1 use adaptive thinking on every request. Their default is `high`; supported\nchoices are `low`, `medium`, `high`, `xhigh`, and `max`, with xcsh's `minimal` choice mapped to\nAnthropic `low`. `off` is rejected because the Fable API does not support disabling thinking.\nFable also does not accept temperature or forced tool selection, so xcsh omits temperature and\nnormalizes `any` or a named forced tool to `auto` while retaining strict tool schemas.\n\nWhen the authenticated ChatGPT subscription catalog includes GPT-6 Astra, `/model` presents it as an additional premium option under **ChatGPT Subscription**. Astra does not replace the existing Luna, Terra, Sol, or role assignments unless you explicitly assign it.\n\nA manual conversation choice remains in effect under automatic routing. Entering planning mode uses the Plan assignment; exiting restores the prior conversation model and reasoning. Explicit `--models` scopes still limit the picker.\n\nOpen `/login` to see providers that are configured, credential-backed, allowlisted, active, or freshly detected. Optional local runtimes do not appear merely because xcsh attempted an automatic probe. Choose `Add provider…` to search the complete built-in catalog.\n\nProvider rows use human status labels. Press Right on a row to inspect its credential source, last verification, sanitized failure reason, model visibility, and any grouped routes. `/logout` lists only providers with stored credentials that xcsh can remove; environment and configuration credentials are not presented as removable.\n\nProvider grouping in `models.yml` is also used by the management view:\n\n```yaml\nproviders:\n  litellm:\n    picker:\n      groupId: litellm\n      groupLabel: LiteLLM\n      sectionLabel: OpenAI\n    modelAllowlist:\n      - gpt-6-astra\n      - gpt-5.6-sol\n      - gpt-5.6-terra\n      - gpt-5.6-luna\n  anthropic:\n    picker:\n      groupId: litellm\n      groupLabel: LiteLLM\n      sectionLabel: Anthropic\n    modelAllowlist:\n      - claude-fable-5-1\n      - claude-fable-5\n      - claude-opus-5\n      - claude-sonnet-5\n      - claude-haiku-4-5\n```\n\n`modelProviderAllowlist` is a settings key that limits normal `/model` visibility. An empty list means no picker restriction; it does not make every built-in provider relevant in `/login`. Explicit provider-qualified command-line selection and direct `/login <provider>` remain available.\n\n```bash\nxcsh config set modelProviderAllowlist '[\"litellm\", \"anthropic\"]'\nxcsh config set modelProviderOrder '[\"litellm\", \"anthropic\", \"google-vertex\"]'\n```\n\nFor command-line selection, qualify the provider whenever several usable providers expose the same model ID. A bare `--model` value succeeds only when one usable provider matches; otherwise xcsh prints the qualified choices and exits nonzero in noninteractive mode.\n\nThe two explicit Fable aliases are an exception to general fuzzy selection:\n\n```bash\nxcsh --model fable\nxcsh --model anthropic/fable\n```\n\nBoth select `anthropic/claude-fable-5-1` deterministically.\n\n## Where does LiteLLM fit?\n\nLiteLLM is an optional provider proxy installed or checked with `xcsh setup litellm`. Its base uniform resource locator (URL) and credential belong in the runtime environment. Successful text Responses support does not imply Realtime or audio support; test the exact endpoint your workflow uses.\n\nGPT-6 Astra has route-specific limits. xcsh-generated LiteLLM configuration exposes the model's full\n1,050,000-token context window (922,000 input plus up to 128,000 output). The ChatGPT Codex subscription\ntransport remains at 272,000 context with the same 128,000 maximum output because upstream deliberately\nkeeps that route in its short-context pricing tier. Both routes support image input and `low`, `medium`,\n`high`, `xhigh`, and `max` reasoning. Astra is selectable explicitly but is not assigned to an automatic\nrole by default.\n\n## How do I test licensed Vertex locally?\n\n`bun run dev` and local coding-agent binary builds load the licensed Vertex OAuth client pair automatically. Explicit `XCSH_VERTEX_OAUTH_CLIENT_ID` and `XCSH_VERTEX_OAUTH_CLIENT_SECRET` build inputs take precedence; supply both together.\n\nFor local UAT, the first launch can recover the embedded client pair from an installed official xcsh binary\nand retain it in `$XDG_CONFIG_HOME/xcsh/vertex-build.json` (default `~/.config/xcsh/vertex-build.json`). The\nfile is outside the checkout, shared by local sessions and worktrees for the same operating-system user, and\ncreated with owner-only permissions. Each worktree needs this development/build launcher to load it\nautomatically. Later launches reuse it even if the installed binary changes.\n`XCSH_VERTEX_OAUTH_CREDENTIALS_FILE` selects another private local file containing `clientId` and\n`clientSecret` fields.\n\nThe source-runtime preload keeps the pair in process memory; local compiled candidates embed it. Do not copy\nthis file or its values into source control, logs, or UAT reports. CI does not read or recover workstation\ncredentials: official release builds continue to receive the pair through GitHub secrets. Unit tests use\nfixture credentials; the live provider smoke script uses the same local preload as development UAT.\n\nRoute selection is complete only when the provider, account, and model all match the intended\nboundary. Use `/model` in the TUI or the explicit model flag shown by `xcsh --help`, send a no-tool\nidentity prompt, and inspect the session metadata. Switching a model affects subsequent turns; it\ndoes not rewrite earlier entries. Remove temporary route overrides and start a new session to verify\nthe default path independently.\n",
 	"en/configure-secure/sandbox-boundaries.mdx": "---\ntitle: \"Set sandbox boundaries\"\ndescription: \"Constrain filesystem, shell, native, browser, and extension effects at the layer that enforces them.\"\nsidebar:\n  order: 5\n  label: \"Sandbox boundaries\"\n---\n\nA model instruction is not a sandbox. Enforcement belongs to the tool, host process, container, operating system, or remote service that performs the action.\n\n## How do I restrict the exposed tool set?\n\nStart with `--no-tools` or an explicit `--tools` allow-list when a run needs only conversation. Disable Model Context Protocol (MCP) and extensions separately because they can register additional capabilities. Review custom tool and hook code with the same care as any locally executed module.\n\n## How do I constrain files and processes?\n\nFilesystem-aware tools resolve paths against their configured workspace boundary. The Bash runtime applies its sandbox and output limits before returning a result; large output may spill to an artifact instead of remaining inline. Containers add process and filesystem isolation, but mounted credentials and sockets still cross that boundary.\n\n## Where does remote authority differ from local authority?\n\nBrowser, editor, Office, and remote-service integrations enforce different permission models. Confirm the active host, account, context, namespace, and target immediately before a mutation. A successful read proves connectivity, not authorization for a write.\n\nSandboxing constrains the local tool implementation; it does not grant remote authority and it\ncannot retract a side effect already accepted by an external service. Begin with no tools, add the\nminimum file or process capability, and test an allowed path plus a denied path. Verify denial at\nthe tool boundary and inspect the filesystem or process table for absence of change. Restore the\nnarrower configuration after the test.\n",
 	"en/configure-secure/secrets-obfuscation.mdx": "---\ntitle: \"Resolve secrets safely\"\ndescription: \"Reference sensitive values without placing plaintext credentials in prompts, manifests, logs, or commits.\"\nsidebar:\n  order: 4\n  label: \"Resolve secrets safely\"\n---\n\nKeep provider keys and F5 Distributed Cloud contexts outside prompts, session exports, logs, and committed files. Pass secrets through supported environment or protected runtime files.\n\n## How does obfuscation work?\n\nWhen secret obfuscation is enabled, values declared in the protected `secrets.yml` source are resolved at runtime and replaced in observable text before it is retained or rendered. Environment values take their documented precedence over file-backed values.\n\nObfuscation reduces accidental disclosure in supported paths; it is not encryption for a compromised process or an excuse to place secrets in prompts.\n\n## How does the filesystem boundary work?\n\nxcsh discovers a task root and guards access outside it. Add an explicit path with `--allow-path`; use `--allow-home` only when the home directory is intentionally the task root. `--no-sandbox` removes that guard and should be reserved for a controlled diagnostic.\n\n## How do I inspect the boundary?\n\nRun `xcsh sandbox check`, then start a read-only session with the smallest required `--allow-path` set. A sandbox boundary limits file discovery; it does not replace operating-system permissions or tool review.\n\nRedaction reduces accidental disclosure in model and display paths; it is not encryption and does\nnot make a committed secret safe. Test with a synthetic value in an isolated process, inspect the\nprompt, tool result, logs, and exported session, then unset the value and remove the temporary rule.\nIf any surface retains the literal, stop before using a real credential and correct the boundary\nthat emitted it.\n",
 	"en/configure-secure/settings-files.mdx": "---\ntitle: \"Understand settings precedence\"\ndescription: \"Predict which user, project, environment, and command-line value xcsh resolves.\"\nsidebar:\n  order: 1\n  label: \"Settings precedence\"\n---\n\nProject settings apply to one repository; user settings apply across projects; command flags override both for one invocation. Use `xcsh config list --json` to inspect effective values.\n\n## How is configuration resolved?\n\nDiscovery collects fixed user, project, environment, and command-line sources, normalizes each through the schema-backed configuration wrapper, then resolves values by explicit priority. Capability-specific discovery uses the same roots but owns its own merge and deduplication rules. Native `.xcsh` providers participate through the documented provider interface, not an implicit recursive scan.\n\n## Where are settings stored?\n\nRun `xcsh config path` instead of assuming a platform path. Project data uses `.xcsh/`, including `settings.json`, `mcp.json`, contexts, skills, agents, extensions, tools, hooks, commands, and `XCSH.md`. Primary user data lives under the xcsh agent directory; `PI_CODING_AGENT_DIR` can override that location.\n\n## How do I change one value?\n\n```bash\nxcsh config get <KEY>\nxcsh config set <KEY> <VALUE>\nxcsh config reset <KEY>\n```\n\nUse environment variables for credentials and ephemeral process configuration. Do not copy an entire old settings file when only one key is needed.\n\nChange one key in the narrowest applicable scope and restart xcsh before judging precedence. Use `/settings` or a schema-backed read path to inspect the effective value; do not infer it from the file you edited. Project settings can affect collaborators, while user settings affect other worktrees on the same account. Revert the test key and confirm a new process resolves the prior value.\n",