github/github-mcp-server · error

lockdown cache is not configured

Error message

lockdown cache is not configured

What it means

Inside get_pull_request_review_comments: the per-request feature flags say LockdownMode is on (ff.LockdownMode from deps.GetFlags), but the cache handle returned by GetRepoAccessCache is nil. In RequestDeps, GetRepoAccessCache returns (nil, nil) exactly when the server-level lockdownMode flag is off — so this error is a configuration split-brain: feature flags enable lockdown while the server itself was not started with it.

Source

Thrown at pkg/github/pullrequests.go:528

	if gqlParams.After != nil {
		vars["after"] = githubv4.String(*gqlParams.After)
	} else {
		vars["after"] = (*githubv4.String)(nil)
	}

	// Execute GraphQL query
	var query reviewThreadsQuery
	if err := gqlClient.Query(ctx, &query, vars); err != nil {
		return ghErrors.NewGitHubGraphQLErrorResponse(ctx,
			"failed to get pull request review threads",
			err,
		), nil
	}

	// Lockdown mode filtering
	if ff.LockdownMode {
		if cache == nil {
			return nil, fmt.Errorf("lockdown cache is not configured")
		}

		// Iterate through threads and filter comments
		for i := range query.Repository.PullRequest.ReviewThreads.Nodes {
			thread := &query.Repository.PullRequest.ReviewThreads.Nodes[i]
			filteredComments := make([]reviewCommentNode, 0, len(thread.Comments.Nodes))

			for _, comment := range thread.Comments.Nodes {
				login := string(comment.Author.Login)
				if login != "" {
					isSafeContent, err := cache.IsSafeContent(ctx, login, owner, repo)
					if err != nil {
						return nil, fmt.Errorf("failed to check lockdown mode: %w", err)
					}
					if isSafeContent {
						filteredComments = append(filteredComments, comment)
					}
				}

View on GitHub (pinned to 0ea1f775a7)

Solutions

1. Start the server with lockdown mode enabled (--lockdown-mode / LOCKDOWN_MODE) so RequestDeps actually builds the cache
2. Align remote feature-flag payloads with server configuration before rollout — don't let flags get ahead of the binary
3. If lockdown is intentionally off, clear the LockdownMode feature flag for this deployment
4. For embedded use, pass a non-nil RepoAccessCache when constructing BaseDeps with LockdownMode=true

Example fix

// before: flag says lockdown, server doesn't support it
flags.LockdownMode = true
// server started without --lockdown-mode → GetRepoAccessCache returns nil, nil

// after: fail fast at startup instead of per-request
if flags.LockdownMode && !serverLockdownMode {
	log.Fatal("lockdown feature flag enabled but server lockdown mode is off; start with --lockdown-mode")
}

// Startup consistency check: feature flag vs server capability
if flags.LockdownMode && !cfg.LockdownMode {
	return fmt.Errorf("lockdown feature flag is enabled but the server was not started with lockdown mode; restart with --lockdown-mode or clear the flag")
}

if ff.LockdownMode && cache == nil {
	return nil, fmt.Errorf("lockdown cache is not configured") // configuration bug — do not retry
}

When it happens

Trigger: Remote GitHub App feature-flag payloads (or a stale flag cache) enabling lockdown while the server runs without --lockdown-mode; BaseDeps wired with a nil RepoAccessCache in an embedded deployment that also sets the lockdown flag.

Common situations: Rollout drift during lockdown-mode migration: flags updated on the App side before the server container is restarted with the new env; test harnesses constructing deps by hand with Flags.LockdownMode=true but no cache; multi-tenant deployments where one tenant's flags leak into another.

Related errors

• failed to get repo access cache: %w
• failed to check lockdown mode: %w
• failed to get GitHub client: %w
• failed to get GitHub client: %w
• failed to get GitHub client: %w

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