chenhg5/cc-connect · error

resolve cc-connect executable for Agy hook: %w

Error message

resolve cc-connect executable for Agy hook: %w

What it means

The permission bridge needs the absolute path of the cc-connect binary to embed as the hook command in the generated hooks.json. If os.Executable fails (cannot determine the running executable's path), createAgyConfigOverlay returns this wrapped error.

Source

Thrown at agent/antigravity/permission_bridge.go:134

		return "", err
	}

	hooks := make(map[string]json.RawMessage)
	hooksPath := filepath.Join(realConfigDir, "hooks.json")
	if data, err := os.ReadFile(hooksPath); err == nil {
		if err := json.Unmarshal(data, &hooks); err != nil {
			return "", fmt.Errorf("parse existing Agy hooks %s: %w", hooksPath, err)
		}
		if hooks == nil {
			hooks = make(map[string]json.RawMessage)
		}
	} else if !os.IsNotExist(err) {
		return "", fmt.Errorf("read existing Agy hooks %s: %w", hooksPath, err)
	}

	executable, err := os.Executable()
	if err != nil {
		return "", fmt.Errorf("resolve cc-connect executable for Agy hook: %w", err)
	}
	bridgeHook, err := json.Marshal(map[string]any{
		"PreToolUse": []any{
			map[string]any{
				"matcher": "*",
				"hooks": []any{
					map[string]any{
						"type":    "command",
						"command": shellQuote(executable) + " _agy-permission-hook",
						"timeout": 86400,
					},
				},
			},
		},
	})
	if err != nil {
		return "", fmt.Errorf("marshal Agy permission hook: %w", err)
	}

View on GitHub (pinned to 4000b2338a)

Solutions

  1. Run cc-connect from a stable installed binary path, not a temporary build output that gets deleted.
  2. Restart cc-connect after upgrading/replacing the binary so os.Executable resolves a valid path.
  3. Avoid deleting or moving the executable while the process runs (use atomic install: write new file, rename over old).
  4. If using `go run`, build a binary first (`go build -o /usr/local/bin/cc-connect`) and run that instead.

Example fix

// before
go run ./cmd/cc-connect   # temp binary may be removed
// after
go build -o /usr/local/bin/cc-connect ./cmd/cc-connect && /usr/local/bin/cc-connect
Defensive patterns

Strategy: fallback

Validate before calling

// shell: ensure the running binary exists on disk before relying on hooks
pidBin=$(readlink -f /proc/$$/exe)
[ -x "$pidBin" ] || echo "running executable missing from disk"

Try / catch

if err := startAntigravitySession(); err != nil && strings.Contains(err.Error(), "resolve cc-connect executable") {
    // restart the process from a stable installed path
}

Prevention

When it happens

Trigger: newAgyPermissionBridge → createAgyConfigOverlay when os.Executable returns an error — essentially only when the executable has been deleted or renamed after start, or on exotic platforms where /proc-style lookup fails.

Common situations: cc-connect binary deleted/replaced on disk while running (e.g. after an upgrade with an installer that unlinks first), running via a wrapper that removed the temp binary (go run scratch builds that vanish), or unusual chroot environments.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors


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