command-code 1.71.0 → 1.72.1

package/CHANGELOG.md

@@ -1,5 +1,18 @@
 # command-code
 
+## 1.72.1
+
+### Patch Changes
+
+- feat: update byok packages
+
+## 1.72.0
+
+### Minor Changes
+
+- feat: add `cmd mods enable <name>` / `cmd mods disable <name>` to enable/disable mods
+- feat: /rc to remote control the session from Telegram and Discord
+
 ## 1.71.0
 
 ### Minor Changes

package/dist/bundled/command-code-knowledge/reference/custom-slash-commands.md

@@ -90,6 +90,7 @@ Every built-in command, grouped by area. Aliases are shown in parentheses on the
 | `/mcp`                                             | Manage MCP server connections                                                     |
 | `/design [mode]`                                   | Design partner: audit, build, compose, and ship UI - bare `/design` browses modes |
 | `/loop [interval] [task]`                          | Run a task now, then repeat it on a fixed or self-paced schedule ([details](https://commandcode.ai/docs/loop)) |
+| `/rc [mode\|off\|status]`                           | Drive this session from Telegram or Discord ([details](https://commandcode.ai/docs/rc))                      |
 | `/import [claude\|codex\|cursor\|pi\|opencode\|gemini]` | Import your setup from another coding agent; bare `/import` imports from all sources |
 | `/taste`                                           | Manage Taste learning and usage                                                   |
 | `/learn-taste`                                     | Learn taste from sessions with other coding agents (Claude Code, Cursor, etc)     |
@@ -164,6 +165,10 @@ Most other commands - `/clear`, `/mode`, `/plan`, `/model`, `/compact`, `/worktr
 
 `/loop <interval> <task>` runs the task now and repeats it on a fixed cadence such as `5m`, `2h`, `1d`, or a trailing `every 2 hours`. `/loop <task>` runs it now and lets the agent pick each next delay, between one minute and one hour. Bare `/loop` runs the default maintenance task, which a `.commandcode/loop.md` file replaces. Esc cancels the conversation's loops. The [`/loop`](https://commandcode.ai/docs/loop) page has the normalization rules, `loop.md`, and resume behavior.
 
+### `/rc` in detail
+
+Bare `/rc` opens the picker: platform, setup, permission mode. `/rc default`, `/rc auto-accept` and `/rc yolo` connect straight into a mode. `/rc status` reports what is on, `/rc off` disconnects, and `/rc off clear` also deletes the bot's own messages. `/rc` is refused when the model asks for it and when it arrives from the chat, so the bot cannot change its own token or allowlist. See [`/rc`](https://commandcode.ai/docs/rc) for setup and what the chat can send.
+
 ---
 
 ## Custom slash commands

package/dist/bundled/command-code-knowledge/reference/product-help.md

@@ -55,6 +55,7 @@
 - /hotkeys: Show all keyboard shortcuts
 - /todos: Manage the session todo list — x to remove an item, c to clear
 - /loop [interval] [task]: Re-run a task on fixed intervals, or let the agent pace itself
+- /rc: Remote-control this session from Telegram or Discord
 - /plan [task]: Enter plan mode; `/plan <task>` plans that task
 - /mode [name]: Show or switch the permission mode — /mode [default|accept-edits|plan]
 - /mode:default: Switch to default mode (prompt before edits/commands)

package/dist/bundled/mod-builder/reference/overview.md

@@ -188,6 +188,14 @@ Command Code's own features ride this exact API. First-party providers (`provide
 {"mods": {"disabled": ["provider-copilot", "update-notice", "titling", "learning"]}}
 ```
 
+A built-in can also ship **opt-in** - off by default; `cmd mods list --builtin` marks it `off by default`. Enable mods with `cmd mods enable <name>` (project level; `-g` for the user level), which adds it to the `enabled` key in the settings file:
+
+```json
+{"mods": {"enabled": ["<name>"]}}
+```
+
+`cmd mods disable <name>` disables the mod. A disable in any settings file wins and keeps the mod disabled. The change takes effect on the next session or `/reload`; see [Enable/Disable a mod](https://commandcode.ai/docs/mods#enabledisable-a-mod).
+
 Built-in mods always win a name collision against a discovered mod of the same name (the loader shadows the file with a warning), and they are compiled in - never jiti-loaded from a writable path, so they are not supply-chain surface. Structural harness mods (workspace, compaction, checkpoints) are load-bearing for correctness and stay unconditional; only the observer-style built-ins above are disable-able.
 
 ---

package/dist/bundled/mod-builder/reference/packaging.md

@@ -16,6 +16,8 @@ cmd mods list                               # alias: cmd mods ls
 cmd mods update                             # reinstall missing, reconcile pinned refs (alias: up)
 cmd mods remove owner/repo                  # alias: cmd mods rm
 cmd mods remove fun-stuff                   # by the name `mods list` prints
+cmd mods enable <name>                      # enable a mod; -g for user level
+cmd mods disable <name>                     # disable a mod; -g for user level
 cmd mods open                               # open the mods dir (project); --user for ~
 ```
 
@@ -64,13 +66,33 @@ A `mods.sources` entry can be the object form to load only part of a package:
 
 Four pattern kinds, applied in precedence order: `-path` force-exclude (exact, beats everything) → `+path` force-include (exact, restores what globs dropped) → `!glob` exclude → plain-glob include (when any includes exist, an entry must match one). Patterns match the entry's package-relative path or its mod name. `cmd mods add` / `remove` preserve hand-written object entries - they never flatten your filters.
 
-## Disabling without deleting
+## Enable/Disable a mod
+
+`cmd mods disable <name>` disables a mod without removing it, and `cmd mods enable <name>` enables it again. Both write the project level (`.commandcode/settings.json`) by default, or the user level (`~/.commandcode/settings.json`) with `-g` flag, and take effect on the next session or `/reload`:
+
+```bash
+cmd mods disable review-guard        # disable in this project
+cmd mods enable review-guard -g      # enable at the user level
+```
+
+They work for discovered files, installed packages, and the disable-able built-ins (`provider-copilot`, `update-notice`, `titling`, `learning` etc). The `cmd mods disable` command adds the name to `mods.disabled`; `cmd mods enable` removes it from there and, for an opt-in built-in, adds it to `mods.enabled`:
 
 ```json
-{"mods": {"disabled": ["review-guard"]}}
+{"mods": {"disabled": ["review-guard"], "enabled": ["<opt-in-built-in>"]}}
 ```
 
-Works for discovered files, installed packages, and the disable-able built-ins (`provider-copilot`, `update-notice`, `titling`, `learning`).
+Disabling a mod anywhere will keep a mod disabled. Command Code reads the user, project, and project-local (`.commandcode/settings.local.json`) settings file, and a `mods.disabled` entry in any of them keeps the mod off, even when another file enables it. So when another settings file still disables the mod you enable, the command does not report success: it names that file, gives the one fix, and exits 1 so a script's `&&` chain stops:
+
+```bash
+$ cmd mods enable review-guard
+⚠ review-guard is still disabled
+  Your user settings (~/.commandcode/settings.json) disable it.
+  To enable it at the user level, run: cmd mods enable review-guard -g
+```
+
+A disable in `settings.local.json` has to be removed by hand; no command writes to that file.
+
+**A project you have not used yet:** Project settings are read only once Command Code has run in that project, the same gate project mods follow. Enabling or disabling there still saves the setting, which applies once you start Command Code in the project; use `-g` to apply it at the user level right away.
 
 ## Trust and safety