github/github-mcp-server · critical

lockdown cache is not configured

Error message

lockdown cache is not configured

What it means

authorLockdownResult enforces lockdown mode and intentionally fails closed: when the passed *lockdown.RepoAccessCache is nil it returns this error instead of allowing access. The cache is constructed at server startup when lockdown mode is enabled, so a nil cache here means the read tool (issue/PR detail) was invoked with lockdown active but the cache was never wired in — a server configuration/wiring defect, not a caller mistake.

Source

Thrown at pkg/github/lockdown.go:25

	"github.com/modelcontextprotocol/go-sdk/mcp"

	"github.com/github/github-mcp-server/pkg/lockdown"
	"github.com/github/github-mcp-server/pkg/utils"
)

// Restriction messages returned when lockdown mode withholds content from a read tool.
const (
	lockdownPullRequestRestrictedMessage = "access to pull request is restricted by lockdown mode"
	lockdownIssueRestrictedMessage       = "access to issue details is restricted by lockdown mode"
)

// authorLockdownResult returns a restricted tool result when content authored by
// authorLogin cannot be surfaced for owner/repo under lockdown mode, and (nil, nil)
// when access is permitted. It should only be called when lockdown mode is enabled.
// It fails closed: a missing cache, an empty author, or a lookup error denies access.
func authorLockdownResult(ctx context.Context, cache *lockdown.RepoAccessCache, owner, repo, authorLogin, restrictedMessage string) (*mcp.CallToolResult, error) {
	if cache == nil {
		return nil, fmt.Errorf("lockdown cache is not configured")
	}
	if authorLogin == "" {
		return utils.NewToolResultError(restrictedMessage), nil
	}
	isSafeContent, err := cache.IsSafeContent(ctx, authorLogin, owner, repo)
	if err != nil {
		return utils.NewToolResultError(fmt.Sprintf("failed to check lockdown mode: %v", err)), nil
	}
	if !isSafeContent {
		return utils.NewToolResultError(restrictedMessage), nil
	}
	return nil, nil
}

View on GitHub (pinned to 0ea1f775a7)

Solutions

  1. Ensure the server is started through the standard entrypoints (cmd/github-mcp-server, pkg/http) so the RepoAccessCache is built when lockdown is enabled
  2. If embedding, construct lockdown.NewRepoAccessCache(gqlClient, restClient, opts...) and set it on BaseDeps.RepoAccessCache / RequestDeps.RepoAccessOpts
  3. Upgrade github-mcp-server in case the nil-cache path is a fixed wiring bug
  4. Do not attempt to bypass: the guard is fail-closed by design

Example fix

// before
deps := github.NewBaseDeps(nil, tc, rc, pc, nil /* cache */, true, nil)
// after
cache := lockdown.NewRepoAccessCache(gqlClient, restClient)
deps := github.NewBaseDeps(nil, tc, rc, pc, cache, true, nil)
Defensive patterns

Strategy: validation

Validate before calling

// Before serving traffic with lockdown enabled, assert the cache is wired:
if cfg.LockdownMode && repoAccessCache == nil {
    log.Fatal("lockdown mode enabled but RepoAccessCache is nil — refusing to start")
}

Type guard

func hasLockdownCache(cache *lockdown.RepoAccessCache) bool {
	return cache != nil
}

Try / catch

if err != nil && strings.Contains(err.Error(), "lockdown cache is not configured") {
    // Server misconfiguration. Stop retrying; fix startup wiring or disable lockdown mode.
}

Prevention

When it happens

Trigger: Lockdown mode is enabled and a read tool (e.g. get_issue/get_pull_request paths that call authorLockdownResult) runs against a server whose dependency injection did not include a RepoAccessCache — e.g. a custom embedding or a hand-built BaseDeps with RepoAccessCache left nil.

Common situations: Embedding github-mcp-server programmatically and enabling lockdown without passing the cache; a bug in a server version where the cache is only built on certain startup paths; running tests with stub deps that omit the cache.

Related errors


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