need RFD 076 — Tool Access Grants

[rxgrant]

Project has a build process (similar to code generation) that confuses the LLM, despite explicit instructions to leave the built files alone. Because questions occasionally arise, the direcory is not suitable for .ignore.

Anyway, need RFD-076.

[JeanMertz]

Are you re-using JP's development tools in this project, or do you have bespoke tools written yourself/using the LLM?

I assume you are re-using JP's dev tools. The good news is that, since #727, parts of RFD 076 have already been implemented. E.g. for the fs_modify_file tool, you can see:

jp/.config/jp/tools/src/fs/modify_file.rs

Lines 112 to 115 in 1489a05

	if let Err(msg) = authorize(ctx.access.as_ref(), Capability::Update, &resolved.relative)
	{
	return error(msg);
	}

Which goes through:

jp/.config/jp/tools/src/fs/utils.rs

Lines 12 to 43 in 1489a05

	/// Enforce an access-policy capability on a resolved workspace-relative path.
	///
	/// `relative` must be the resolver's output (`ResolvedPath::relative`), not the
	/// raw tool input: for in-workspace paths that form has its symlinked ancestors
	/// canonicalized, so a path reached via an in-workspace symlink is matched
	/// against the rule for its real location rather than the rule for the link
	/// name.
	/// External (approved-mount) paths keep their lexical mount-relative form,
	/// which is what external rules match on.
	///
	/// A `None` policy (or an unrestricted one) permits everything.
	/// A restricted policy permits only what a matching rule grants; on denial the
	/// configured grant paths are listed so the user can see what the tool is
	/// allowed to do.
	pub fn authorize(
	access: Option<&AccessPolicy>,
	capability: Capability,
	relative: &Utf8Path,
	) -> Result<(), String> {
	let Some(policy) = access else {
	return Ok(());
	};
	if policy.permits(capability, relative) {
	return Ok(());
	}
	let grants: Vec<&str> = policy.grant_paths().map(Utf8Path::as_str).collect();
	Err(format!(
	"Access denied: cannot {} '{relative}'. Granted paths: [{}].",
	capability.as_str(),
	grants.join(", ")
	))
	}

So you can now configure the access field on a tool config:

jp/crates/jp_config/src/conversation/tool.rs

Lines 409 to 416 in 1489a05

	/// Filesystem access grants for the tool.
	///
	/// Declares which workspace-relative paths the tool may touch and what it
	/// may do there.
	/// When absent, the tool keeps unrestricted (but workspace-confined)
	/// access; declaring any rule switches the tool to default-deny.
	#[setting(nested)]
	pub access: Option<AccessConfig>,

With the config syntax shown here:

jp/crates/jp_config/src/conversation/tool/access.rs

Lines 1 to 21 in 1489a05

	//! Filesystem access grants for a tool.
	//!
	//! `access.fs` declares which paths a tool may touch and what it may do there.
	//! When the section is absent the tool keeps unrestricted (workspace-confined)
	//! access; declaring at least one rule switches the tool to default-deny.
	//!
	//! ```toml
	//! [[conversation.tools.fs_modify_file.access.fs]]
	//! path = "."
	//! read = true
	//!
	//! [[conversation.tools.fs_modify_file.access.fs]]
	//! path = "fork"
	//! external = true
	//! read = true
	//! write = true
	//! ```
	//!
	//! A rule with `external = true` acknowledges that its `path` is a symlink that
	//! resolves outside the workspace; the canonical target is approved host-side
	//! on first use.

I've only used this in relation to https://jp.computer/rfd/drafts/D43-tool-access-to-external-paths-via-workspace-symlinks, so do give me feedback if you try it using access.fs.write and run into any issues.