oh-my-customcode 0.173.0 → 0.174.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/cli/index.js +1 -1
- package/dist/index.js +1 -1
- package/package.json +1 -1
- package/templates/.claude/rules/MUST-agent-design.md +10 -0
- package/templates/.claude/rules/MUST-agent-teams.md +12 -0
- package/templates/.claude/rules/MUST-permissions.md +12 -0
- package/templates/manifest.json +1 -1
package/dist/cli/index.js
CHANGED
package/dist/index.js
CHANGED
package/package.json
CHANGED
|
@@ -27,6 +27,16 @@ tools: [Read, Write, ...] # Allowed tools
|
|
|
27
27
|
|
|
28
28
|
Extended context suffix: `[1m]` (e.g., `claude-opus-4-6[1m]`) — enables 1M token context window.
|
|
29
29
|
|
|
30
|
+
### Fallback Models (CC v2.1.166+)
|
|
31
|
+
|
|
32
|
+
> **v2.1.166+**: The `fallbackModel` setting configures up to three fallback models tried in order when the primary model is overloaded or unavailable. `--fallback-model` now also applies to interactive sessions. CC additionally retries a turn once on the fallback model when the API rejects an unexpected non-retryable error (auth, rate-limit, request-size, and transport errors still surface immediately).
|
|
33
|
+
|
|
34
|
+
This is a settings-level resilience mechanism, distinct from the per-agent `model:` frontmatter. It complements the `model-escalation` skill (outcome-based escalation) by handling availability/overload failover at the platform level.
|
|
35
|
+
|
|
36
|
+
### Thinking Toggle (CC v2.1.166+)
|
|
37
|
+
|
|
38
|
+
> **v2.1.166+**: `MAX_THINKING_TOKENS=0`, `--thinking disabled`, and the per-model thinking toggle disable thinking on models that think by default via the Claude API (3rd-party providers unchanged). Relevant when an agent's `effort` is low and thinking overhead is undesirable.
|
|
39
|
+
|
|
30
40
|
### Optional Frontmatter
|
|
31
41
|
|
|
32
42
|
Key optional fields: `memory`, `effort`, `skills`, `soul`, `isolation`, `background`, `maxTurns`, `maxTokens`, `mcpServers`, `hooks`, `permissionMode`, `disallowedTools`, `limitations`, `domain`, `disableSkillShellExecution`. Supported since CC v2.1.63+. See full optional frontmatter via Read tool.
|
|
@@ -36,6 +36,18 @@ Available when `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` or TeamCreate/SendMessag
|
|
|
36
36
|
|
|
37
37
|
These are distinct mechanisms. Agent Teams `SendMessage` requires `TeamCreate` and operates within a single Claude Code session. claude-peers-mcp `send_message` operates across separate Claude Code processes via a localhost broker.
|
|
38
38
|
|
|
39
|
+
### Cross-Session Relay Authority Hardening (CC v2.1.166+)
|
|
40
|
+
|
|
41
|
+
> **v2.1.166+**: Messages relayed via `SendMessage` from other Claude sessions no longer carry user authority — receivers refuse relayed permission requests, and auto mode blocks them. A relayed message cannot escalate privilege on the receiving session.
|
|
42
|
+
|
|
43
|
+
| Aspect | Behavior (v2.1.166+) |
|
|
44
|
+
|--------|---------------------|
|
|
45
|
+
| Relayed permission request | Refused by receiver |
|
|
46
|
+
| Auto mode + relayed request | Blocked |
|
|
47
|
+
| User authority across relay | Not propagated |
|
|
48
|
+
|
|
49
|
+
This hardens cross-session coordination (claude-peers-mcp `send_message`, see Scope table above) against privilege escalation — a relayed message from session A cannot grant session B permissions the user did not authorize on B. Aligns with R001 (credential/privileged-scope guardrails) and R010 (out-of-scope privileged chaining). Intra-session Agent Teams `SendMessage` between peers in the same session is unaffected.
|
|
50
|
+
|
|
39
51
|
## Self-Check (Before Agent Tool)
|
|
40
52
|
|
|
41
53
|
Before using Agent tool for 2+ agent tasks, complete this check:
|
|
@@ -33,6 +33,18 @@ Approve?
|
|
|
33
33
|
|
|
34
34
|
On insufficient permission: do not attempt, notify user, suggest alternative.
|
|
35
35
|
|
|
36
|
+
## Deny Rule Glob Patterns (CC v2.1.166+)
|
|
37
|
+
|
|
38
|
+
> **v2.1.166+**: Deny rules support glob patterns in the tool-name position — `"*"` in a deny rule denies all tools. Allow rules reject non-MCP globs (only MCP tool-name globs are accepted in the allow position). Unknown tool names in deny rules emit a startup warning.
|
|
39
|
+
|
|
40
|
+
| Position | Glob support |
|
|
41
|
+
|----------|-------------|
|
|
42
|
+
| Deny rule tool-name | Yes — `"*"` denies all tools |
|
|
43
|
+
| Allow rule tool-name | MCP globs only; non-MCP globs rejected |
|
|
44
|
+
| Unknown tool in deny rule | Startup warning |
|
|
45
|
+
|
|
46
|
+
Use a `"*"` deny rule in `settings.json` to enforce a deny-by-default posture, then add specific allow rules. Complements the Tier-based policy above — settings.json deny rules are evaluated by the CC platform, independent of the advisory tier table.
|
|
47
|
+
|
|
36
48
|
## Agent Tool Permission Mode
|
|
37
49
|
|
|
38
50
|
When spawning subagents via the Agent tool, always pass `mode: "bypassPermissions"` explicitly. The Agent tool's default mode is `acceptEdits`, which **overrides** the agent frontmatter `permissionMode` field.
|
package/templates/manifest.json
CHANGED