fix: reset Hive to thin upstream parity

[100yenadmin]

Outcome

Resets Hive onto pinned upstream Buzz main at dd222a509b156ba52ed3219e895d7bf1cf322c92 and replays only the thin Electric/Hermes seams required by Hive #36.

Native Buzz startup, collaboration, settings, Huddles, drafts, channels, DMs, profiles, and product surfaces remain active. Electric OAuth selects and authorizes one company community; ordinary collaboration remains user-signed and relay-enforced.

Included

• Hermes and hermes-acp runtime discovery with dependency readiness separate from launch-time ACP authentication discovery.
• Durable ACP channel/session continuity and invalidation behavior.
• Direct member disconnect plus durable membership revalidation capped at 15 seconds for delegated agents.
• Bounded shared metadata polling for channel create/update and DM open.
• Thin macOS Keychain identity plus revocable Electric desktop session adapter.
• Native Agents catalog enriched by company-scoped VM agent public identities.
• Hive branding, compatible deep links, package assets, and an isolated signed-fork updater contract.
• Tested managed settings policy: hide only Compute, Hosted communities, and Mobile; restore native Agents, Templates, Experiments, Custom emoji, Local archive, and Updates.

Explicitly removed from the previous candidate

• Managed channel/DM brokers and control-identity collaboration writes.
• Duplicate collaboration screens.
• Blanket native command guards and broad settings hiding.
• Session-owned recipient identity.

Focused proof on behavior head ae735034cd47d165c21d2fc05d77ab6ac994fa7d

• Managed auth/key custody and logout recovery: 22 Rust tests passed.
• Native and managed desktop deep-link scheme routing: 2 focused Rust tests passed.
• Hermes discovery/auth contract: 6 passed, 1 intentional subprocess fixture ignored.
• Metadata read-after-write polling: 3 passed.
• ACP durable session store: 6 passed.
• ACP DM authorization including upstream fix(acp): restrict DM turns to owner and verified siblings block/buzz#2591: 4 passed.
• Relay membership principal/agent disconnect tenant fence: 1 passed.
• Desktop parity/product/agent/settings/onboarding tests: 52 passed.
• Managed settings/company-agent catalog: 4 focused tests passed.
• TypeScript typecheck, desktop checks, managed-feature Clippy, Rust format, file-size guard, and diff checks passed.
• Independent semantic review and final targeted delta review passed; all nine GitHub review threads have terminal dispositions and are resolved.

The current PR head adds only a validated fork-portable Docker cache/image namespace correction after that behavior review.

Proof boundary

This draft PR is source and focused-test evidence only. It does not claim merge, signed artifact, deployment, installed two-user canary, VM mutation, customer rollout, or public release. Durable identity/session-grant database changes and Golden VM packaging are staged as separate linked PRs so this upstream-first desktop/relay diff stays reviewable.

Tracks #36 and parent #1.

[chatgpt-codex-connector]

💡 Codex Review

evaOS-Hive/crates/buzz-relay/src/state.rs

Lines 195 to 196 in 6d5c0af

	for (community_id, membership_pubkey) in manager.live_membership_principals() {
	match check_member(community_id, membership_pubkey.clone()).await {

Bound the complete membership revalidation pass

Fresh evidence against the earlier delegated-agent tradeoff is that the advertised 15-second bound applies only to the timer interval: every live principal is checked sequentially here, with no per-query or whole-pass timeout. With enough principals, a saturated pool, or one slow database query, a removed principal later in the set can keep receiving community traffic far beyond 15 seconds after a missed Redis disconnect; batch or concurrently bound these checks so the complete pass—not merely its scheduling interval—meets the revocation limit.

---

evaOS-Hive/desktop/src/features/settings/ui/SignOutSection.tsx

Lines 51 to 53 in 6d5c0af

	getEvaosTeamsAuthStatus()
	.then((status) => {
	if (current) setManaged(status.managed);

Avoid refreshing auth just to choose the sign-out UI

Fresh evidence after the SettingsView fix is that opening Profile still mounts this independent entitlement refresh solely to determine whether the build is managed. If the remote refresh has a transient failure, the Rust command returns reauth_required and disables evaos_teams_authorized, while EvaosTeamsAuthGate retains its prior active state until its own timer fires—potentially an hour later—so the normal app stays visible while writes fail; derive this branch from desktopProductPolicy().managed instead.

---

evaOS-Hive/crates/buzz-acp/src/session_store.rs

Lines 29 to 34 in 6d5c0af

	let runtime = serde_json::to_vec(&(agent_command, agent_args))
	.expect("serializing strings cannot fail");
	Self {
	relay_hash: hash_bytes(relay_url.as_bytes()),
	agent_pubkey: agent_pubkey.to_ascii_lowercase(),
	runtime_hash: hash_bytes(&runtime),

Include session-defining configuration in the scope hash

When an operator changes system_prompt, team instructions, or the base prompt but keeps the relay, agent key, command, and arguments unchanged, this scope hash remains identical. After restart the durable mapping therefore takes the session/load path and skips session/new, even though protocol-v2 system configuration is delivered only during session/new, leaving the channel on the old instructions indefinitely; hash the session-defining configuration or invalidate mappings when it changes.

---

evaOS-Hive/desktop/src/features/agents/ui/agentConfigOptions.tsx

Lines 421 to 422 in 6d5c0af

	: runtime.availability === "dependency_missing"
	? " (setup needed)"

Update the scoped agent-config guide

This introduces a new rendered dependency_missing configuration state, but the scoped AGENTS.md is unchanged and the change contains no explicit “no rules changed” note. The repository requires every change to how agent configuration is modeled or rendered to update that guide in the same PR, so document the readiness/auth-state behavior and its acceptance gate before landing.

AGENTS.md reference: desktop/src/features/agents/AGENTS.md:L124-L131

---

evaOS-Hive/desktop/src/features/evaosTeams/api.ts

Lines 51 to 53 in 6d5c0af

	export function evaosTeamsRefreshDelay(status: EvaosTeamsAuthStatus) {
	const seconds = status.entitlement?.refreshAfterSeconds ?? 300;
	return Math.min(Math.max(seconds, 30), 3600) * 1000;

Refresh no later than the entitlement expiry

A server response whose expiresAt is sooner than refreshAfterSeconds passes the Rust validation, but this timer uses only refreshAfterSeconds. For example, an entitlement expiring in one minute with a one-hour refresh interval leaves evaos_teams_authorized active for roughly 59 minutes after expiry, during which signing remains enabled; schedule using the minimum of the requested refresh and remaining lifetime, or reject an entitlement whose refresh point is not before expiry.

---

evaOS-Hive/desktop/src/features/settings/ui/SignOutSection.tsx

Lines 74 to 80 in 6d5c0af

	const status = await logoutEvaosTeams();
	if (status.phase !== "signed_out") {
	throw new Error(
	status.message ?? "Hive could not confirm remote session revocation.",
	);
	}
	window.location.reload();

Reset the active community when switching memberships

After managed sign-out, this reload preserves the previous active-community record in local storage. If the user then selects another membership whose entitlement points at a different relay, NativeBuzzApp remounts with the old relay and apply_workspace rejects it because managed workspaces must match the new entitlement; if both memberships share a relay, old community-scoped UI state can instead be presented under the new identity. Clear or replace the active managed community with the newly authenticated entitlement before remounting.

---

evaOS-Hive/desktop/src-tauri/src/evaos_teams.rs

Lines 62 to 65 in 6d5c0af

	managed_store()
	.replace_all(&existing)
	.map_err(|_| "Hive cannot write to macOS Keychain".to_string())?;
	if managed_store().load_all_readonly()? != Some(existing) {

Perform a real write in the Keychain writability probe

When the existing map is passed unchanged to replace_all, SecretStore::mutate_blob detects a no-op and deliberately skips write_blob_raw, so this function proves only that the Keychain is readable. In a read-allowed/write-denied Keychain state, Hive opens the browser and completes the full device flow before credential persistence finally fails; use a reversible probe value or a backend operation that actually exercises write permission before starting login.

---

evaOS-Hive/desktop/src-tauri/src/evaos_teams.rs

Lines 670 to 673 in 6d5c0af

	*app_state
	.relay_url_override
	.lock()
	.map_err(|error| error.to_string())? = Some(relay);

Route first-time setup through the entitled relay

Installing the entitlement writes the selected relay only to relay_url_override, but the no-community startup path calls get_default_relay_url, which still returns the static environment/build default and never reads this override. On a fresh Hive profile where that default differs from the server-selected relay, onboarding proposes the wrong community and the subsequent managed apply_workspace call rejects it, leaving the user unable to reach the entitled community; expose the active override to first-community initialization.

---

evaOS-Hive/crates/buzz-relay/src/handlers/event.rs

Lines 661 to 665 in 6d5c0af

	if state.config.require_relay_membership {
	match state
	.db
	.is_relay_member(conn.tenant.community(), &membership_pubkey.to_hex())
	.await

Avoid querying membership for every WebSocket event

On closed relays this performs a PostgreSQL lookup for every EVENT before even the pubkey, scope, kind, or signature checks. An authenticated socket can therefore stream malformed frames and turn each cheap rejection into a database query, while normal high-rate typing or observer traffic also adds one query per frame; this can exhaust the pool and stall the relay. Use a bounded positive-membership cache tied to the revalidator, or perform admission/rate checks before touching the database.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".