Connect the sources your task needs.

Start with a provider

The runtime has provider implementations for GitHub, GitLab, Jira, Postgres, MCP bridges and configurable HTTP sources. Each has its own credentials, resource types and permissions.

Use the provider’s configuration contract rather than assuming the same fields work for every service. Do not commit access tokens into project configuration.

Provide credentials to the runtime

Set credentials in the environment of the process that launches LeanCTX. A terminal’s environment is not automatically inherited by an already-running desktop host.

Provider	Recognized environment	Scope
GitHub	GITHUB_TOKEN, then GH_TOKEN, then LEAN_CTX_GITHUB_TOKEN	GITHUB_REPOSITORY (owner/repo) or a detected Git remote
GitLab	LEAN_CTX_GITLAB_TOKEN, then GITLAB_TOKEN, then CI_JOB_TOKEN	CI_PROJECT_PATH or a matching remote; host from GITLAB_HOST, then CI_SERVER_HOST, otherwise gitlab.com
Jira	JIRA_URL, JIRA_EMAIL, JIRA_TOKEN, JIRA_PROJECT	Deployment selected with JIRA_DEPLOYMENT; Cloud is the default

The token order is fallback order, not a request to set every variable. Jira also has an OAuth path for Cloud; server deployments and OAuth do not share one authentication contract. Use credentials with only the remote permissions your workflow needs.

Inspect the configured surface

{"name":"ctx_provider","arguments":{"action":"list"}}

Then use a provider and resource returned by the runtime. The provider schema lists actions and inputs; discovery does not grant access to a resource.

A configured source may still be unavailable because of authentication, network policy, rate limits or permissions.

Understand consolidation

Supported provider results can be consolidated into retrieval chunks, graph relationships and project knowledge. That makes external material available to the context pipeline; it does not mean every provider is queried on every task.

Respect source identity and freshness. Cached data is a retained observation, not a promise that a remote issue or database row is unchanged.

Review query and data scope

Limit issue filters, repository scope and database permissions to the task. A connector’s access is also bounded by the remote account. Reading sensitive information into a local cache may have retention implications.

In organizational deployments, bind the request to an authorized end-user or workload identity before acquisition. Broad service credentials are not proof of that subject’s permission. Unknown permissions deny access; discovery or a successful connection does not grant it.

For PostgreSQL, expose explicitly permitted tables or views and bounded read-only records. Keep row and source scope under the authenticated request. Do not pass unrestricted, agent-authored SQL through a connector. A schema describes the data; it does not replace actual authorized records when the task needs them.

Keep source state current

Retain source identity, revision, provenance and freshness with each result. Distinguish a known refresh time from unknown freshness. Refresh, supersession, revocation and deletion affect what may be retrieved next; a cached result cannot bypass current access checks.

For ordinary URLs and remote Git reads, see web and research. For downstream MCP tool discovery, use MCP connections.

Engine contract & references8 references · Reviewed 20 Sept 2026

• registry.rsrust/src/core/providers/registry.rsGitHub
• config.rsrust/src/core/providers/config.rsGitHub
• github.rsrust/src/core/providers/github.rsGitHub
• gitlab.rsrust/src/core/providers/gitlab.rsGitHub
• jira.rsrust/src/core/providers/jira.rsGitHub
• postgres.rsrust/src/core/providers/postgres.rsGitHub
• mod.rsrust/src/core/providers/config_provider/mod.rsGitHub
• ctx_provider.rsrust/src/tools/ctx_provider.rsGitHub

Engine concepts describe responsibilities and behavior. Exact commands, package versions and platform contracts belong to their versioned references.

Versions & compatibility