Scaled-Tech-Consulting/Gitea-Tools
2
0
Fork 0
Code Issues 6 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Support separate Gitea MCP runtime profiles via environment configuration #19

New Issue
Closed
opened 2026-07-01 11:30:22 -05:00 by jcwalker3 · 2 comments
jcwalker3 commented 2026-07-01 11:30:22 -05:00
Owner
Copy Link
Copy Source

Parent

Roadmap #10 — Task-scoped MCP execution profiles for LLM-operated Gitea workflows

Problem

We want roles to be fluid across LLM sessions, but safe. The LLM should not be the role; the MCP credential/profile should be the role.

To support this, the same Gitea MCP server should be runnable as separate configured MCP instances, each with its own token and profile name.

Scope

Support runtime configuration for separate Gitea MCP profiles, such as:

  • gitea-author
  • gitea-reviewer
  • gitea-merger
  • gitea-owner

Each runtime profile should be configured through environment variables or a safe secret provider.

Example env names:

GITEA_BASE_URL=https://gitea.example.invalid
GITEA_TOKEN=replace-with-token
GITEA_PROFILE_NAME=gitea-reviewer
GITEA_ALLOWED_OPERATIONS=read,review,approve

Acceptance criteria

  • Gitea MCP can run as multiple separate MCP server entries using different env tokens.
  • Each runtime exposes a safe profile name.
  • Tokens are never logged.
  • Tokens are never returned by tools.
  • .env.example contains placeholders only.
  • Real token files are gitignored.
  • Existing Gitea MCP behavior is not broken.
  • This supports future whoami and reviewer eligibility checks.

Non-goals

  • Do not implement multi-token switching inside one unsafe runtime.
  • Do not expose token values.
  • Do not add Jenkins, Ops, GlitchTip, deploy, or production behavior.

Proposed labels

mcp · gitea · security

## Parent Roadmap #10 — Task-scoped MCP execution profiles for LLM-operated Gitea workflows ## Problem We want roles to be fluid across LLM sessions, but safe. The LLM should not be the role; the MCP credential/profile should be the role. To support this, the same Gitea MCP server should be runnable as separate configured MCP instances, each with its own token and profile name. ## Scope Support runtime configuration for separate Gitea MCP profiles, such as: * `gitea-author` * `gitea-reviewer` * `gitea-merger` * `gitea-owner` Each runtime profile should be configured through environment variables or a safe secret provider. Example env names: ```dotenv GITEA_BASE_URL=https://gitea.example.invalid GITEA_TOKEN=replace-with-token GITEA_PROFILE_NAME=gitea-reviewer GITEA_ALLOWED_OPERATIONS=read,review,approve ``` ## Acceptance criteria * Gitea MCP can run as multiple separate MCP server entries using different env tokens. * Each runtime exposes a safe profile name. * Tokens are never logged. * Tokens are never returned by tools. * `.env.example` contains placeholders only. * Real token files are gitignored. * Existing Gitea MCP behavior is not broken. * This supports future `whoami` and reviewer eligibility checks. ## Non-goals * Do not implement multi-token switching inside one unsafe runtime. * Do not expose token values. * Do not add Jenkins, Ops, GlitchTip, deploy, or production behavior. ## Proposed labels `mcp` · `gitea` · `security`
jcwalker3 added the mcpsecuritygitea labels 2026-07-01 11:30:29 -05:00
jcwalker3 commented 2026-07-01 21:57:32 -05:00
Author
Owner
Copy Link
Copy Source

Reopened + claimed. Implementing the canonical single-file runtime-profiles config: one GITEA_MCP_CONFIG JSON with multiple named profiles selected via GITEA_MCP_PROFILE; thin per-LLM launchers carry only those two env vars; typed auth references (keychain id / env name) so no raw tokens live in LLM configs. Env-only behavior preserved. Branch: feat/issue-19-canonical-runtime-profiles.

Reopened + claimed. Implementing the canonical single-file runtime-profiles config: one `GITEA_MCP_CONFIG` JSON with multiple named profiles selected via `GITEA_MCP_PROFILE`; thin per-LLM launchers carry only those two env vars; typed auth references (keychain id / env name) so no raw tokens live in LLM configs. Env-only behavior preserved. Branch: `feat/issue-19-canonical-runtime-profiles`.
jcwalker3 added the status:in-progress label 2026-07-01 21:57:40 -05:00
jcwalker3 commented 2026-07-01 22:05:04 -05:00
Author
Owner
Copy Link
Copy Source

Update: implemented on the existing PR #30 (branch feat/json-runtime-profiles), reworked to the canonical single-file schema — not a separate branch. #19 kept open + claimed so PR #30 tracks/completes it. Canonical config: version + profiles with typed auth references ({type: keychain|env}); thin LLM launchers carry only GITEA_MCP_CONFIG + GITEA_MCP_PROFILE; env-only mode preserved.

Update: implemented on the existing PR #30 (branch `feat/json-runtime-profiles`), reworked to the canonical single-file schema — not a separate branch. #19 kept open + claimed so PR #30 tracks/completes it. Canonical config: `version` + `profiles` with typed `auth` references ({type: keychain|env}); thin LLM launchers carry only GITEA_MCP_CONFIG + GITEA_MCP_PROFILE; env-only mode preserved.
sysadmin removed the status:in-progress label 2026-07-02 01:30:57 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
chore
documentation
Docs / runbooks
 gitea
Gitea MCP workflow
 important
mcp
MCP server / tooling
 mutating
Mutating action; requires gating
 nice-to-have
read-only
Read-only, no mutation
 roadmap
Roadmap / umbrella issue
 security
Security / trust boundary
 status:in-progress
Issue is being worked on
No Label gitea mcp security
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
jcwalker3 sysadmin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#19
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?