fix(supervise): provision MCP via claude mcp add #25
@@ -237,8 +237,22 @@ def _apply_pipelock_url(slug: str, failed_url: str) -> tuple[str, str]:
|
|||||||
full allowlist. Extract the host, merge into the running
|
full allowlist. Extract the host, merge into the running
|
||||||
allowlist, and hand the merged content to apply_allowlist_change.
|
allowlist, and hand the merged content to apply_allowlist_change.
|
||||||
The full URL (with path) is preserved on the proposal for the
|
The full URL (with path) is preserved on the proposal for the
|
||||||
operator's read; only the host ends up in pipelock's allowlist
|
operator's read; only the host ends up in pipelock's allowlist.
|
||||||
(pipelock can't enforce path-level rules)."""
|
|
||||||
|
FOLLOW-UP — path-aware filtering. Pipelock 2.3.0's api_allowlist
|
||||||
|
is hostname-only (verified by inspecting the binary's strict
|
||||||
|
preset; the only "path" fields in pipelock's schema are about
|
||||||
|
local filesystem paths under sandbox / file_sentry / taint). So
|
||||||
|
approving pipelock-block opens the entire host, not the URL's
|
||||||
|
path. If/when per-path enforcement becomes load-bearing, the
|
||||||
|
follow-up is most likely adding an `auth_scheme: none` mode +
|
||||||
|
`path_allowlist` field to cred-proxy (which already does
|
||||||
|
path-prefix routing) and rewiring pipelock-block to propose
|
||||||
|
cred-proxy routes instead of pipelock hostnames. That's a
|
||||||
|
multi-touch change deserving its own PRD — out of scope for the
|
||||||
|
supervise-loop work that introduced this function. See PR
|
||||||
|
discussion on https://gitea.dideric.is/didericis/claude-bottle/pulls/25
|
||||||
|
for the design conversation."""
|
||||||
import urllib.parse
|
import urllib.parse
|
||||||
parsed = urllib.parse.urlsplit(failed_url.strip())
|
parsed = urllib.parse.urlsplit(failed_url.strip())
|
||||||
host = parsed.hostname or ""
|
host = parsed.hostname or ""
|
||||||
|
|||||||
Reference in New Issue
Block a user