{"record":{"id":"db5f4fb60a35d73c","repo":"zeroclaw-labs/zeroclaw","slug":"channel-does-not-support-room-invites","errorCode":null,"errorMessage":"channel does not support room invites","messagePattern":"channel does not support room invites","errorType":"exception","errorClass":"anyhow::Error","httpStatus":null,"severity":"error","filePath":"crates/zeroclaw-api/src/channel.rs","lineNumber":909,"sourceCode":"\n    /// Redact (delete) a message from the channel.\n    async fn redact_message(\n        &self,\n        _channel_id: &str,\n        _message_id: &str,\n        _reason: Option<String>,\n    ) -> anyhow::Result<()> {\n        Ok(())\n    }\n\n    /// Create a new platform room/conversation when the channel supports it.\n    async fn create_room(&self, _options: &RoomCreationOptions) -> anyhow::Result<String> {\n        anyhow::bail!(\"channel does not support room creation\")\n    }\n\n    /// Invite a user to an existing platform room/conversation.\n    async fn invite_user(&self, _room_id: &str, _user_id: &str) -> anyhow::Result<()> {\n        anyhow::bail!(\"channel does not support room invites\")\n    }\n\n    /// Request interactive tool-call approval from the channel operator.\n    ///\n    /// Returns `Ok(Some(response))` when the operator answers within the\n    /// channel's configured `approval_timeout_secs`; timeouts surface as\n    /// `Deny`. Returns `Ok(None)` only for channels that do not implement\n    /// the prompt at all — the caller falls back to its default policy\n    /// (typically auto-deny).\n    async fn request_approval(\n        &self,\n        _recipient: &str,\n        _request: &ChannelApprovalRequest,\n    ) -> anyhow::Result<Option<ChannelApprovalResponse>> {\n        Ok(None)\n    }\n\n    /// Like [`Channel::request_approval`], but also reports WHO produced the","sourceCodeStart":891,"sourceCodeEnd":927,"githubUrl":"https://github.com/zeroclaw-labs/zeroclaw/blob/88bb9c8533fc57ed7a03e36ca7c9ed2bf8336dcc/crates/zeroclaw-api/src/channel.rs#L891-L927","documentation":"Phase 5 of `zeroclaw update` (src/commands/update.rs:266) — swap_binary replaces the current executable (Unix: remove then copy; Windows: rename the running exe to a pid-suffixed sidecar, then copy the new one in). When the swap fails, run() attempts rollback_binary from the `<exe>.bak` backup made in Phase 3; if rollback also fails it prints \"CRITICAL: Rollback also failed\" plus a manual `cp` recovery line, then bails with this message. Typical root causes are filesystem-level: install dir not writable at swap time (permissions changed after the preflight), disk full during the copy, EPERM/ETXTBSY removing the old binary, or a Windows file lock (antivirus scanning the new image).","triggerScenarios":"`zeroclaw update` reaching Phase 5 and swap_binary erroring: tokio::fs::remove_file/copy/rename failing on the install path — e.g. system-wide install where write access was lost, no space left on device, an AV or indexer holding the new binary on Windows, or a network/noexec mount.","commonSituations":"Updating a system-wide install without sudo (the Phase-1 writability preflight usually catches this, but privileges can be dropped later); disk filling up between download and swap; Windows Defender or another AV locking zeroclaw.exe mid-swap; binary installed on NFS.","solutions":["First verify the CLI still runs (`zeroclaw --version`); if not, restore manually with the exact `cp <backup> <exe>` line the command printed (backup lives at <exe>.bak)","Re-run `zeroclaw update` with elevated privileges (sudo on macOS/Linux, Administrator console on Windows) so the swap can write the install dir","Free disk space and ensure the install filesystem is writable and local (not NFS/read-only)","On Windows, exclude the install dir from real-time AV scanning or retry after the scan completes","If swaps keep failing, install from source with ./install.sh --source as a bypass"],"exampleFix":"# before\n$ zeroclaw update\nCRITICAL: Rollback also failed: ... \nManual recovery: cp /usr/local/bin/zeroclaw.bak /usr/local/bin/zeroclaw\nError: Update failed during swap: ... \n\n# after\n$ cp /usr/local/bin/zeroclaw.bak /usr/local/bin/zeroclaw\n$ zeroclaw --version            # confirm the old binary is restored\n$ sudo zeroclaw update          # re-run with write access to the install dir","handlingStrategy":"fallback","validationCode":"// Caller-side preflight mirroring ensure_install_dir_writable:\n// confirm the exe's directory is writable and has room before updating.\nfn install_dir_ready(exe: &std::path::Path) -> anyhow::Result<()> {\n    let dir = exe.parent().unwrap();\n    let probe = dir.join(format!(\".probe-{}\", std::process::id()));\n    std::fs::File::create(&probe)?;\n    std::fs::remove_file(&probe)?;\n    Ok(())\n}","typeGuard":null,"tryCatchPattern":"if let Err(e) = update::run(version, force).await {\n    if e.to_string().contains(\"Update failed during swap\") {\n        // 1. Check the binary still runs: `zeroclaw --version`.\n        // 2. If not, restore from <exe>.bak exactly as the printed\n        //    `Manual recovery: cp ...` line instructs.\n        // 3. Only then re-run update with elevated privileges.\n    }\n}","preventionTips":["Run `zeroclaw update` with write access to the install directory (sudo / Administrator) — the built-in writability preflight is the first line of defense","Ensure free disk space for roughly 2x the binary size (download + backup) before updating","Exit other running zeroclaw/zerocode processes before updating on Windows to avoid file locks","Keep the .bak backup until the new version has been verified in real use"],"tags":["update","binary-swap","permissions","disk-full","rollback","windows-file-lock"],"backgroundTag":"self-update-swap-failed","analyzedSha":"88bb9c8533fc57ed7a03e36ca7c9ed2bf8336dcc","analyzedAt":"2026-08-23T01:07:41.857Z","schemaVersion":2},"datasetVersion":"2026-08-23T08:06:27.607Z"}