github/github-mcp-server · error

lockdown cache is not configured

Error message

lockdown cache is not configured

What it means

GetIssueComments read feature flags saying lockdown mode is ON, but the resolved RepoAccessCache is nil, so it cannot filter comments by author push access and fails fast instead of leaking unvetted content. Under RequestDeps the cache is only constructed when the deps themselves were built with lockdownMode true — a nil cache here means the flag source and the dependency wiring disagree.

Source

Thrown at pkg/github/issues.go:862

		},
	}

	comments, resp, err := client.Issues.ListComments(ctx, owner, repo, issueNumber, opts)
	if err != nil {
		return nil, fmt.Errorf("failed to get issue comments: %w", err)
	}
	defer func() { _ = resp.Body.Close() }()

	if resp.StatusCode != http.StatusOK {
		body, err := io.ReadAll(resp.Body)
		if err != nil {
			return nil, fmt.Errorf("failed to read response body: %w", err)
		}
		return ghErrors.NewGitHubAPIStatusErrorResponse(ctx, "failed to get issue comments", resp, body), nil
	}
	if flags.LockdownMode {
		if cache == nil {
			return nil, fmt.Errorf("lockdown cache is not configured")
		}
		filteredComments := make([]*github.IssueComment, 0, len(comments))
		for _, comment := range comments {
			user := comment.User
			if user == nil {
				continue
			}
			login := user.GetLogin()
			if login == "" {
				continue
			}
			isSafeContent, err := cache.IsSafeContent(ctx, login, owner, repo)
			if err != nil {
				return utils.NewToolResultError(fmt.Sprintf("failed to check lockdown mode: %v", err)), nil
			}
			if isSafeContent {
				filteredComments = append(filteredComments, comment)
			}

View on GitHub (pinned to 0ea1f775a7)

Solutions

1. Make the lockdown setting a single source of truth: when flags can enable lockdown, construct the deps (RequestDeps/BaseDeps) with lockdown mode and cache wiring enabled
2. In custom embeddings, provide a cache via BaseDeps.RepoAccessCache (build one with lockdown.NewRepoAccessCache(gqlClient, restClient))
3. If lockdown was not intended for this deployment, disable the flag
4. For test doubles, return a fake non-nil cache from stubDeps.GetRepoAccessCache

Example fix

// before — flag and wiring disagree
deps := pkggithub.NewRequestDeps(apiHosts, version, t, false /* lockdownMode not passed */)
// ...request arrives with LockdownMode flag = true -> "lockdown cache is not configured"

// after — construct deps from the same config the flags read
deps := pkggithub.NewRequestDeps(apiHosts, version, t, cfg.LockdownMode)

// Assert flag/deps consistency before serving requests
if flagsFromContext.LockdownMode {
    if cache, err := deps.GetRepoAccessCache(ctx); err != nil || cache == nil {
        return fmt.Errorf("lockdown flag set but cache unavailable: %v", err)
    }
}

func isLockdownConfigError(err error) bool {
    return err != nil && strings.Contains(err.Error(), "lockdown cache is not configured")
}

When it happens

Trigger: flags.LockdownMode (from context/request-level flags) is true while RequestDeps.lockdownMode is false, so GetRepoAccessCache returned (nil, nil); or BaseDeps was constructed without a RepoAccessCache while the flag is enabled.

Common situations: Embedding the server and enabling lockdown via request context flags without passing lockdown config into NewRequestDeps; test harnesses with stub deps that enable the flag but return a nil cache; version drift where flag propagation moved to a different layer than cache construction.

Related errors

• lockdown cache is not configured
• failed to marshal response: %w
• failed to query viewer login: %w
• viewer login returned empty
• failed to query repository metadata: %w

AI-assisted analysis of github/github-mcp-server@0ea1f775a7 (2026-08-15). Data as JSON: /api/errors/69550289f3dc8b1f. Report an issue: GitHub.