F-024 S6: in-app MCP capability and project access switches
Maintainers usually reply within 1 day
@PelikanFix16 is already working on this.
Since Oct 6, 2026.
Assessment
This issue has not been assessed yet.
Description
Outcome
Let the authenticated owner control what each personal MCP connection may read, propose and execute through clear switches and selected native project access in Flux. Use the ordinary owner session; do not require password re-entry, a recent-auth/auth_time check, a ten-minute confirmation or a secondary SSO prompt.
Part of #273 / F-024. Required in v0.1. Superseding founder direction from Hubert's supervising session, 2026-10-07, recorded in #360. This replaces the earlier S6 step-up contract. Existing current-rights, consent, standing-grant and runtime boundaries remain.
Acceptance criteria
- AC-1 — Honest, persisted owner controls. A named personal connection has owner-only, persisted and versioned switches for the actual registered read/propose/execute capabilities and selected native projects. Show effective availability and refusal reasons; handle reload, concurrent/stale saves and failures without claiming an unsaved setting succeeded. Unsupported actions stay unavailable. Keep a fully disabled connection manageable by its owner. No recent-auth or second password/SSO challenge.
- AC-2 — Server authority intersection. Every protected read/projection/tool and effect is bounded by current owner rights, actual agent project grants, the disclosed connection/OAuth consent envelope and the live switches. Effects additionally require the existing exact standing grant, runtime/binding, operation/class/object, uses/expiry and current source/version where applicable. Owner labels, admin/manager roles, agent inputs or frontend hiding cannot bypass connection ownership or these checks. A switch cannot grant project/admin/private/DM access or create an owner-paid invocation/decision-acceptance tool. Going outside the original scope/place consent requires normal explicit owner/OAuth authorization and an appropriate token, never a checkbox escalation.
- AC-3 — Off and narrowing are live. A committed Off or narrowing is enforced at the next protected projection/read/list/effect/queued-output or receipt replay check, including an old JWT. Serialize policy changes with protected authorization/effect/delivery rechecks and prove held-request races. Reject pending work truthfully after authority is removed. Preserve earlier committed history; neither already committed effects nor bytes already handed to the transport are retroactively undone, and this does not promise to stop unrelated local CLI work.
- AC-4 — On does not resurrect authority. On may restore only a policy allowed by still-valid consent, current rights and existing bounded grants. It cannot revive a revoked connection/runtime, expired/revoked/used-up grant or authority removed by the owner/IdP. New bounded grants continue the existing disclosed owner plus project.manage authorization routes; no hidden grant creation. Preserve the original consent and receipt identities, using a restrictive versioned policy overlay or an independently reviewed equivalent.
- AC-5 — Integrated evidence. Docker API and browser checks prove owner vs other-owner/admin/agent refusal, persistence/reload, old-token Off/On, failed/stale saves, held projection/effect/delivery races, replay, revocation, expiry, all-disabled management and ordinary no-prompt behavior. Integrate one permissions surface with #343/#347/#350; no competing grant flow. Review the exact final head independently.
Owner: @PelikanFix16. Independent GitHub evaluator: @Zamojski5. Dependencies/interfaces: #310/S1 identity/session confirmation, existing MCP scopes/standing grants and the applicable runtime authorization boundaries; final UI #347/#350. Canonical contract: MCP identity S6, synchronized through #360 / PR #361. Current read/propose/execute creation and revocation routes are not mutable capability switches; implementation is still open.
- Dominant language
- TypeScript
- Stars
- 3
- Forks
- 0
- Avg merge
- 14h 40m
- Merged PRs (30d)
- 242
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ColdPhase/flux
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
F-027 A10 — Connect AI order and labels in Settings (rest of #410)Possibly taken @Zamojski5 claimed this 1 day ago. Open
ColdPhase/flux#493 · 1 comment · 1 assignee ·
Maintainers usually reply within 1 day
Similar issues
-
enhancement
Difficulty 1/5 Under an hour Newbie friendliness 80/100
alunduil/projects-v2-sync#21 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
enhancement minor
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
testcontainers/testcontainers-node#1539 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
christopher-buss/eslint-plugin-flawless#72 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
openwatersio/slackwater-database#281 ·
Maintainers usually reply within 1 day