chenhg5/cc-connect · warning

antigravity: permission request %q is already resolved

Error message

antigravity: permission request %q is already resolved

What it means

RespondPermission delivers the result over a buffered (capacity-1) channel per pending request. If the channel is full, the request was already resolved by a previous response, so this error is returned instead of blocking or double-delivering. It is a duplicate-response guard.

Source

Thrown at agent/antigravity/permission_bridge.go:324

func (b *agyPermissionBridge) RespondPermission(requestID string, result core.PermissionResult) error {
	behavior := strings.ToLower(strings.TrimSpace(result.Behavior))
	if behavior != "allow" && behavior != "deny" {
		return fmt.Errorf("antigravity: invalid permission behavior %q", result.Behavior)
	}
	result.Behavior = behavior

	b.pendingMu.Lock()
	ch := b.pending[requestID]
	b.pendingMu.Unlock()
	if ch == nil {
		return fmt.Errorf("antigravity: unknown permission request %q", requestID)
	}
	select {
	case ch <- result:
		return nil
	default:
		return fmt.Errorf("antigravity: permission request %q is already resolved", requestID)
	}
}

func (b *agyPermissionBridge) Close() {
	b.closeOnce.Do(func() {
		b.cancel()
		_ = b.listener.Close()
		b.wg.Wait()
		_ = os.RemoveAll(b.rootDir)
	})
}

View on GitHub (pinned to 4000b2338a)

Solutions

1. Treat this as benign — the first response already won; disable the buttons after the first click.
2. Track answered request IDs at the call site and skip duplicates before calling RespondPermission.
3. Debounce/deduplicate platform button callbacks (idempotency key = requestID).
4. No recovery is possible for the second call; the result must be considered lost.

Example fix

// before
bridge.RespondPermission(id, result)
bridge.RespondPermission(id, result) // second call errors
// after
if answered[id] { return }; answered[id] = true
bridge.RespondPermission(id, result)

if err := bridge.RespondPermission(id, result); err != nil && strings.Contains(err.Error(), "already resolved") {
    // benign duplicate; log at debug and no-op
}

When it happens

Trigger: Calling RespondPermission twice with the same requestID in quick succession (double-click, retry after a slow response, both allow and deny buttons wired to the same handler).

Common situations: Impatient user tapping a permission button twice; platform retry logic re-posting the callback; two chat members both answering the same shared-session permission card.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

• antigravity: invalid permission behavior %q
• antigravity: unknown permission request %q
• listen for Agy permission hooks: %w
• generate permission bridge token: %w
• resolve home directory for Agy permission bridge: %w

AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06). Data as JSON: /api/errors/e58813d264932e66. Report an issue: GitHub.