claude-use 0.3.6 → 0.4.0

package/README.md

@@ -126,6 +126,8 @@ Every top-level entry in `~/.claude` is classified into one of five categories,
 
 This is a safe-by-default posture: only `knowledge` and `settings` are shared out of the box. A configuration profile can open up `history` (or anything else) wholesale, or share individual items within a closed category.
 
+**`all` is shorthand for every overridable category at once**, for a profile that wants "share everything except credentials" without hand-listing `runtime`, `history`, `knowledge`, and `settings` individually — `{ "categories": { "all": true } }` expands to exactly those four set to `true`. `secret` can never be included, by construction: `all` only ever expands over the four categories a configuration layer is allowed to toggle in the first place, the same restriction a hand-written `categories` object is already under. An explicit named category always wins over `all` in the same object regardless of which one is written first, so `{ "all": true, "runtime": false }` means "share everything except runtime" — the general `all` setting, narrowed by the specific override, matching how a more specific layer already beats a less specific one everywhere else in this cascade. The same shorthand works identically from `--category all=true`/`CLAUDE_USE_CATEGORY_OVERRIDE=all=true` and `claude-use profile set <name> --category all=true`, not just profile JSON files — one expansion, shared by all three input paths.
+
 `secret`'s "never, cannot be overridden" is an absolute check `resolve/decide.ts` makes *before* running the two-phase cascade at all — not merely the least-specific layer in that cascade, the way every other category is. This matters because [The cascade](#the-cascade-how-everything-composes)'s general rule is that a specific `entries` override always beats a category default; `secret` is the one deliberate exception, so an explicit `entries: { "secret/.credentials.json": true }` anywhere in any layer is rejected outright, the same as a bare `categories: { secret: true }` would be — path-specificity never gets a chance to apply to this one category.
 
 **`~/.claude.json` isn't in this table at all, because — unlike `backups/` above — it isn't sourced from `~/.claude` the way everything else here is.** It's a sibling *file* next to the `~/.claude` directory, not an entry inside it: the OAuth session, personal (user/local-scope) MCP server definitions, and per-project trust decisions (which directories you've approved Claude Code to run in, and what it's allowed to do there). It fully relocates to `$CLAUDE_CONFIG_DIR/.claude.json` when set, the same as everything else — confirmed both in Anthropic's own Agent SDK documentation and empirically in this project's own development. Because it's generated fresh by Claude Code itself the moment it first runs under a new `CLAUDE_CONFIG_DIR`, `claude-use` treats it the same way as `secret`: always identity-local, never part of the shared cascade, and — since it isn't even a descendant of `~/.claude` — never something the resolver's directory walk encounters at all, rather than something explicitly excluded by category. `~/.claude/backups/` holds rolling timestamped copies of it (capped at five, auto-rotating) for Claude Code's own config-migration safety; being a genuine descendant of `~/.claude`, it *is* something the resolver walks past, which is exactly why it's listed under `secret` in the table above rather than merely assumed safe.
@@ -493,7 +495,7 @@ install.sh                 # downloads the latest release's binary for the runni
                              # checksum, and installs it as both `claude` and `claude-use` in ~/.local/bin
 ```
 
-`schema.ts` models `categories` and `entries` differently despite their identical JSON-object appearance in every example above, because they have opposite key cardinality: `categories` only ever touches the four overridable names in the [category table](#category-based-sharing), so it's a closed `z.strictObject({ runtime: z.boolean().optional(), history: z.boolean().optional(), knowledge: z.boolean().optional(), settings: z.boolean().optional() })` — deliberately omitting `secret` from the shape entirely, so an attempted `secret` key is rejected at parse time rather than relying only on the runtime check described above — while `entries` is genuinely open-ended (any literal or glob path, each required to carry its `<category>/` prefix per the [Category-based sharing](#category-based-sharing) section above) and stays a `z.record(z.string().regex(ENTRY_KEY_RE), EntryValueSchema)`. The closed shape for `categories` also gives editors real key-name autocomplete from the published JSON Schema (the `schema/` directory above), which a record type can't offer.
+`schema.ts` models `categories` and `entries` differently despite their identical JSON-object appearance in every example above, because they have opposite key cardinality: `categories` only ever touches the four overridable names in the [category table](#category-based-sharing) plus the `all` shorthand, so it's a closed `z.strictObject({ all: z.boolean().optional(), runtime: z.boolean().optional(), history: z.boolean().optional(), knowledge: z.boolean().optional(), settings: z.boolean().optional() })` piped through a `.transform()` that expands `all` into the four real categories and drops it from the result — deliberately omitting `secret` from the shape entirely, so an attempted `secret` key is rejected at parse time rather than relying only on the runtime check described above — while `entries` is genuinely open-ended (any literal or glob path, each required to carry its `<category>/` prefix per the [Category-based sharing](#category-based-sharing) section above) and stays a `z.record(z.string().regex(ENTRY_KEY_RE), EntryValueSchema)`. The closed shape for `categories` also gives editors real key-name autocomplete from the published JSON Schema (the `schema/` directory above) — generated with Zod's `io: "input"` option specifically because a schema with a `.transform()` can't be represented in JSON Schema at all under the default `"output"` mode, and `"input"` is what a hand-written config actually needs describing anyway, which a record type couldn't offer either way.
 
 `ConfigProfile.extends` is a flat `z.array(z.string()).optional()` — a list of other profiles' *names*, resolved by `resolve/extends.ts` loading each named file and walking the resulting graph at runtime. It's correctly **not** a self-referential Zod schema (no `z.lazy()` needed): nothing in `ConfigProfile`'s own shape points back at `ConfigProfile`. Because each profile file validates in isolation, though, Zod has no way to catch a circular `extends` definition (`a` extends `b` extends `a`) — the walker in `resolve/extends.ts` needs its own cycle guard (a visited-set), independent of schema validation.
 

package/dist/cli.cjs

@@ -221857,7 +221857,7 @@ var categories_default_default = {
 // package.json
 var package_default = {
   name: "claude-use",
-  version: "0.3.6",
+  version: "0.4.0",
   description: "A profile manager and launcher for Claude Code that lets one person run multiple logins from one machine while controlling what gets shared between them.",
   license: "Apache-2.0",
   author: "Joseph Mearman <joseph@mearman.co.uk>",
@@ -236532,12 +236532,21 @@ function isOverridableCategory(name) {
 function isCategoryName(name) {
   return CATEGORY_NAMES.some((category) => category === name);
 }
+function expandAllCategoryKey(pairs) {
+  const { all, ...rest } = pairs;
+  if (all === void 0) {
+    return { ...rest };
+  }
+  const expanded = Object.fromEntries(OVERRIDABLE_CATEGORIES.map((category) => [category, all]));
+  return { ...expanded, ...rest };
+}
 var CategoryMapSchema = external_exports.strictObject({
+  all: external_exports.boolean().optional(),
   runtime: external_exports.boolean().optional(),
   history: external_exports.boolean().optional(),
   knowledge: external_exports.boolean().optional(),
   settings: external_exports.boolean().optional()
-});
+}).transform((input) => expandAllCategoryKey(input));
 var DURATION_RE = /^(?:0|[1-9][0-9]*)(?:ms|s|m|h|d|w)$/;
 var DurationSchema = external_exports.string().regex(DURATION_RE);
 var WhenSchema = external_exports.strictObject({
@@ -240394,9 +240403,10 @@ function validateCategoryNames(patch) {
 }
 function setProfileCategories(paths, name, patch) {
   requireProfileExists(paths, name);
-  validateCategoryNames(patch);
+  const expandedPatch = expandAllCategoryKey(patch);
+  validateCategoryNames(expandedPatch);
   const existing = readProfile(paths, name) ?? {};
-  const mergedCategories = { ...existing.categories, ...patch };
+  const mergedCategories = { ...existing.categories, ...expandedPatch };
   return applyPatch(profileJsonPath(paths, name), ConfigProfileSchema, { categories: mergedCategories });
 }
 function setProfileEntries(paths, name, patch) {
@@ -241459,8 +241469,9 @@ var InvalidCliEntryKeyError = class extends Error {
   key;
 };
 function toCategoryMap(pairs) {
+  const expanded = expandAllCategoryKey(pairs);
   const result = {};
-  for (const [key, value] of Object.entries(pairs)) {
+  for (const [key, value] of Object.entries(expanded)) {
     if (!isOverridableCategory(key)) {
       throw new InvalidCliCategoryError(key);
     }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-use",
-  "version": "0.3.6",
+  "version": "0.4.0",
   "description": "A profile manager and launcher for Claude Code that lets one person run multiple logins from one machine while controlling what gets shared between them.",
   "license": "Apache-2.0",
   "author": "Joseph Mearman <joseph@mearman.co.uk>",