@brutalsystems/muster 1.0.1 → 1.1.0

package/CANONICAL_ID.md

@@ -1,6 +1,6 @@
 # Tin Can — Address Format
 
-> **Normative for `@brutalsystems/tincan` 1.9.2.**
+> **Normative for `@brutalsystems/tincan` 2.0.0.**
 >
 > This describes what Tin Can does today, precisely enough for another tool to
 > produce addresses Tin Can will resolve. It is a write-down of shipped
@@ -335,7 +335,10 @@ afterwards that the other tool disagreed.
 So:
 
 - **A change to any behaviour described here is a breaking change**, and ships
-  as a major version under semver.
+  as a major version under semver. The converse does not hold, and 2.0.0 is the
+  standing example: it marks the repository being republished with a new
+  history, and **nothing in this document changed with it**. If you implement
+  against this format, 2.0.0 requires nothing of you.
 - Update this document and the fixture in the same commit as the code.
 - Adding cases to the fixture is not a breaking change. Changing an existing
   expected value is.

package/CONTRACT_PROVENANCE.md

@@ -481,3 +481,84 @@ as a re-copy signal.
 updating the fixture moved CI on its own — the first cut where the failure class
 that produced v0.9.0 had nothing to act on. The drift hashes still moved, which
 is the third site behaving exactly as documented above.
+
+## Re-sync to Tin Can 2.0.0 — 2026-09-26
+
+Copies are from tag `v2.0.0`, commit `c588e8b3e119c530e55c8e59be892133f7b49631`.
+
+| File | SHA-256 |
+| --- | --- |
+| `CANONICAL_ID.md` | `609634a58df2e288542732a3c95037a3e57efcaf63a36c26f6a4a7251c4804f2` |
+| `test/fixtures/canonical-id.json` | `bf686e97d91cba3bd3ee51ecb6d74ccf5e4978b3fcb783e441b1c01de5135285` |
+
+`tincan_version: 2.0.0`, still 40 cases: 8 slugify, 7 suffix, 12 assignment,
+13 resolution. The format did not move. 2.0.0 is a major because Tin Can's
+repository was republished with a new history and npm reserves a version
+number forever — not because anything in the address format changed. Upstream
+says so in the copy itself, in a paragraph added to `CANONICAL_ID.md`'s
+"Changing this format": 2.0.0 "requires nothing of you".
+
+**The usual verification was not available, and the substitute is better here.**
+Every previous entry checked the claim by diffing upstream across the two tags
+— `v1.7.0..v1.9.2` last time. That is impossible now: the republish left
+tincan with a two-commit history and exactly one tag, so `v1.9.2` is not a
+revision in that repository any more and never will be. What was diffed instead
+is muster's own vendored copies, which *are* still in muster's history, against
+the `v2.0.0` tag content. That answers muster's actual question — what changed
+between what was vendored and what is being vendored — without depending on
+upstream's history at all, and it is the form future re-syncs should take.
+
+The entire delta across both files is three hunks:
+
+- `CANONICAL_ID.md`: the normative version line, `1.9.2` → `2.0.0`.
+- `CANONICAL_ID.md`: the new paragraph described above.
+- the fixture: `tincan_version`, and one `rawName` in the prefix-collision
+  case, `cxx-be` → `billing-api`.
+
+`naming.ts` does not appear and no expected value moved. The renamed peer is
+**input**, not an expected output, and that case's expected `canonicalId`
+names the *other* peer (`muster-b1`), so the rename cannot change what the
+case asserts. It is upstream removing a string that reads as a client project
+name, which is also why it was worth taking promptly rather than at the next
+convenient re-sync: `test/fixtures/canonical-id.json` is in `package.json`'s
+`files`, so the old string shipped in every tarball up to and including 1.0.1.
+
+**No pin edit, again.** The pins derive from `tincan_version`, so updating the
+fixture moved `publish.yml`, `RELEASING.md` and `docs/verification.md` on
+their own. Only the two frozen hashes in `test/naming.test.ts` are hand-written,
+and those are the third site behaving as documented.
+
+## What the vendored copy covers, and what it deliberately does not
+
+The copies pin **the address format Muster generates** — slugify, suffix,
+assignment, resolution — and the refusals that resolution can produce:
+`ambiguous`, `self`, `unknown`. That is the whole surface, and the boundary is
+not an accident of what was convenient to copy.
+
+They do **not** cover Tin Can's send-path vocabulary, because Muster never calls
+`send_peer` in product code. Muster produces addresses; Tin Can does the
+sending. The only mentions of that call in this repository are a doc comment in
+`naming.ts` describing what an address is for, and the contract suite asserting
+`outcome === "accepted"` on the happy path. Neither enumerates a refusal, so
+there is no unknown-refusal path here for a new one to fall through.
+
+Tin Can 2.0.0 is the worked example. It added a `duplicate_peer_moved` refusal,
+splitting the retry-whose-name-has-moved case out of `duplicate_send`. A
+consumer of send outcomes had to act on that — birddog did, and it was a real
+change for them. Muster owed nothing, and the 2.0.0 re-sync above correctly
+shows no such edit. The asymmetry is clean: Muster produces addresses and never
+consumes send outcomes; birddog consumes send outcomes and never produces an
+address. Neither repository inherits the other's obligations, and a vendored
+contract that tried to cover both would be wrong in both directions.
+
+**So the question at each re-sync is not "did Tin Can change".** It is: did
+anything Muster *generates or parses* change. Copying more than that is not
+caution, it is over-vendoring — it pins a surface Muster does not use, and the
+frozen hashes in `test/naming.test.ts` then move for reasons that have nothing
+to do with Muster, which is how a freeze stops meaning anything.
+
+**If Muster ever grows a send path, this boundary moves and the copy must widen
+with it** — `duplicate_peer_moved` and the rest of the send vocabulary would
+become a genuine re-sync obligation, and a re-sync that kept ignoring them would
+be a defect. Recorded now, while the reasoning is fresh, rather than discovered
+by whoever adds that path.

package/dist/guard.js

@@ -443,6 +443,14 @@ export function launchArgs(req, config, mcp = [], bridgePath, env = process.env)
     const settings = {
         ...profilePluginSettings(configDir),
         disableAllHooks: true,
+        // `--setting-sources ""` means an acceptance recorded in the profile's
+        // settings.json is never read, so without this the bypass warning stops
+        // every bypass launch before it registers (#45). Only on request, and
+        // `assertOptionsSupported` has already refused it outside bypass.
+        ...(req.options.includes("accept-bypass-warning") &&
+            policy.permissions === "bypass"
+            ? { skipDangerousModePermissionPrompt: true }
+            : {}),
         permissions: {
             defaultMode: mode,
             allow: mcp.flatMap((s) => s.config.tools.map((t) => `mcp__${s.name}__${t}`)),

package/dist/help.js

@@ -60,7 +60,7 @@ export const COMMANDS = [
             ["--mcp NAME", "repeatable; replaces configured defaults"],
             [
                 "--options NAME",
-                "repeatable; muster-side launch options — auto-approve-path records the launch directory as trusted so its one-time dialog does not block the launch (claude and codex only, and refused if the directory ships hooks or MCP servers)",
+                "repeatable; muster-side launch options — auto-approve-path records the launch directory as trusted so its one-time dialog does not block the launch (claude and codex only, and refused if the directory ships hooks or MCP servers); accept-bypass-warning accepts Claude's one-time Bypass Permissions warning so a --level open launch can start (claude with bypass permissions only)",
             ],
             ["--no-mcp", "launch with no MCP servers"],
             ["--plugin NAME", "repeatable; replaces configured defaults (OpenCode)"],

package/dist/identity/claude.js

@@ -64,22 +64,27 @@ export async function claudeWorkspaceTrusted(env, cwd) {
  * timeout looks identical to a hung or crashed launch. Several unrelated
  * screens can produce it, and the old message guessed at two of them together.
  * Trust is the one Muster can actually check, so it is either named or ruled
- * out. Nothing else is named: a first-use bypass-permissions confirmation was
- * a plausible account of one report, but no profile on this machine carries a
- * key for it the way they carry `hasSeenAutoModeEntryWarning` and its
- * siblings, so this says "another one-time confirmation" rather than sending
- * the reader after a screen nobody has demonstrated.
+ * out. The bypass-permissions warning is named only for a launch that ran in
+ * bypass without `accept-bypass-warning`: demonstrated in #45, and that launch
+ * is the only one it can stop. Anything else says "another one-time
+ * confirmation" rather than sending the reader after a screen nobody has
+ * demonstrated.
  *
  * A `--kind task` launch into the same directory is the cheap discriminator:
  * it runs headless and never sees the dialog, so it succeeds where a session
  * hangs.
  */
-export function claudeRegistryDiagnostic(trusted, cwd, configDir) {
+export function claudeRegistryDiagnostic(trusted, cwd, configDir, opts = {}) {
     if (!trusted)
         return (`no Claude session registry found: workspace trust has not been ` +
             `accepted for ${cwd} in ${configDir} — accept it once with ` +
             `\`cd ${cwd} && claude\`, then retry (trust is per-directory and is ` +
             `not inherited from a parent directory)`);
+    if (opts.bypassWarningPending)
+        return (`no Claude session registry found (${cwd} is trusted for this profile): ` +
+            `this launch runs in bypass permissions, and Claude stops on its ` +
+            `one-time "Bypass Permissions mode" warning until someone answers it — ` +
+            `relaunch with --options accept-bypass-warning to accept it for the launch`);
     return (`no Claude session registry found (${cwd} is trusted for this profile, ` +
         `so the session is stopped on something else — check the terminal for a ` +
         `login prompt or another one-time confirmation)`);

package/dist/mcp-tools.js

@@ -63,8 +63,11 @@ export const MCP_TOOLS = [
                 },
                 options: {
                     type: "array",
-                    items: { type: "string", enum: ["auto-approve-path"] },
-                    description: "Muster-side launch options. auto-approve-path records the launch directory as trusted in the profile the agent will use, so its one-time dialog does not block the launch; refused for a runtime with no trust gate, and refused if the directory ships hooks or MCP servers. Not expressible remotely.",
+                    items: {
+                        type: "string",
+                        enum: ["auto-approve-path", "accept-bypass-warning"],
+                    },
+                    description: "Muster-side launch options. auto-approve-path records the launch directory as trusted in the profile the agent will use, so its one-time dialog does not block the launch; refused for a runtime with no trust gate, and refused if the directory ships hooks or MCP servers. accept-bypass-warning accepts Claude's one-time Bypass Permissions warning for a bypass launch (level open); refused for other runtimes and without bypass permissions. Not expressible remotely.",
                 },
                 project: {
                     type: "string",

package/dist/options.js

@@ -10,17 +10,31 @@ import { AGENTS } from "./agents.js";
  * in its own way, or cannot express at all — so the set is closed, and naming
  * one an agent has no answer for is an error rather than a silent no-op.
  */
-export const LAUNCH_OPTIONS = ["auto-approve-path"];
+export const LAUNCH_OPTIONS = [
+    "auto-approve-path",
+    "accept-bypass-warning",
+];
 /**
  * Refuses an option the runtime cannot honour, before anything is reserved or
  * spawned. `auto-approve-path` records that the launch directory is trusted, so
  * it needs an agent with a trust gate to record it in; OpenCode has none, and
  * accepting the flag there would promise something muster cannot deliver.
+ *
+ * `accept-bypass-warning` answers Claude's one-time "Bypass Permissions mode"
+ * warning, which only Claude shows and only in bypass. Anywhere else there is
+ * no warning to accept, so it is refused rather than carried as a no-op that
+ * reads like consent to something.
  */
-export function assertOptionsSupported(runtime, options) {
-    for (const option of options)
+export function assertOptionsSupported(runtime, options, permissions) {
+    for (const option of options) {
         if (option === "auto-approve-path" && !AGENTS[runtime].trustWorkspace)
             throw new Error(`--options auto-approve-path is not supported for ${runtime}: it has no workspace-trust gate`);
+        if (option === "accept-bypass-warning" && runtime !== "claude")
+            throw new Error(`--options accept-bypass-warning is not supported for ${runtime}: only Claude shows a bypass-permissions warning`);
+        if (option === "accept-bypass-warning" &&
+            permissions.permissions !== "bypass")
+            throw new Error(`--options accept-bypass-warning requires bypass permissions (--level open or --permissions bypass); this launch resolves to ${permissions.permissions}`);
+    }
 }
 /**
  * What a directory ships that would configure a session it is trusted by.

package/dist/run.js

@@ -256,10 +256,10 @@ export class Muster {
         if (req.open &&
             (req.kind !== "session" || !["auto", "tmux"].includes(requestedHost)))
             throw new Error("--open requires a tmux session on macOS");
+        const permissions = resolvePermissions(effective, this.config);
         // Refused here, with the other checks that cost nothing to fail: an option
         // the runtime cannot honour must not leave a registry entry behind.
-        assertOptionsSupported(req.runtime, req.options);
-        const permissions = resolvePermissions(effective, this.config);
+        assertOptionsSupported(req.runtime, req.options, permissions);
         const enforcement = enforcementGrade(req.runtime, permissions);
         assertEnforcementMeetsMinimum(req.runtime, enforcement, policy);
         // Composed here, before any process of any kind is started — the version
@@ -736,7 +736,11 @@ export class Muster {
         // runs headless and never sees the dialog, so refusing an untrusted
         // directory up front would break task launches that work today.
         if (req.runtime === "claude" && diagnostic === neverRegistered)
-            diagnostic = claudeRegistryDiagnostic(await claudeWorkspaceTrusted(resolveEnv, req.cwd), req.cwd, claudeConfigDir(resolveEnv));
+            diagnostic = claudeRegistryDiagnostic(await claudeWorkspaceTrusted(resolveEnv, req.cwd), req.cwd, claudeConfigDir(resolveEnv), {
+                bypassWarningPending: req.kind === "session" &&
+                    permissions.permissions === "bypass" &&
+                    !req.options.includes("accept-bypass-warning"),
+            });
         throw new Error(`${diagnostic} after ${this.config.launch_timeout_sec}s`);
     }
     async launch(input, requester) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@brutalsystems/muster",
-  "version": "1.0.1",
+  "version": "1.1.0",
   "description": "Launch instructed, reachable local agent sessions",
   "type": "module",
   "engines": {

package/test/fixtures/canonical-id.json

@@ -1,6 +1,6 @@
 {
   "$comment": "FROZEN. Describes @brutalsystems/tincan address behaviour as shipped. Adding cases is fine; changing an expected value means the address format changed - see CANONICAL_ID.md, 'Changing this format'.",
-  "tincan_version": "1.9.2",
+  "tincan_version": "2.0.0",
   "spec": "CANONICAL_ID.md",
   "slugify": [
     {
@@ -576,7 +576,7 @@
         },
         {
           "runtime": "claude-code",
-          "rawName": "cxx-be",
+          "rawName": "billing-api",
           "uuid": "33333333-3333-4333-8333-333333333333"
         }
       ],