# The access policy never reaches a custom argument formatter

- **Status**: Todo
- **Kind**: Bug
- **Authors**: jp
- **Date**: 2026-09-04
- **Implements**: 076
- **Label**: package=jp_cli
- **Label**: package=jp_tool
- **Label**: type=bug

A local tool with `style.parameters = "<command>"` runs that command with a
`Context` whose `access` field is absent, so it deserializes as `None` —
indistinguishable from "this tool has no access grants".

`format_args_custom` builds the context JSON by hand
(`crates/jp_cli/src/render/tool.rs:812-823`) with `action`, `root`,
`workspace_id`, and `conversation_id`, and nothing else.
The `Run` path does plumb the compiled policy (`execute_local` takes `access:
Option<&jp_tool::AccessPolicy>`, `crates/jp_llm/src/tool.rs:832`), so the same
tool binary sees its grants for one action and not the other.

RFD 076 Phase 3 covers both halves and only one shipped:

> Include access policy in the JSON context passed to tool commands in
> `execute_local()` and the `FormatArguments` path.

## What this is not

Enforcement is cooperative.
`run_tool_command` never clears the environment
(`crates/jp_llm/src/tool.rs:461`), so a local tool binary can read any variable
with `std::env::var` on either path, policy or no policy.
Passing the policy to the formatter does not create a boundary that isn't there
on the `Run` path.

The defect is narrower and worth fixing on its own terms: a tool author who
*wants* their formatter to honour the grants it was given has no way to read
them.
A formatter that renders a preview of what a call will touch cannot say "this
variable is denied" without them.

## Scope

- Compile the policy once and pass it into both context constructions, rather
  than compiling it twice with two chances to diverge.
- A test covering both `Action::Run` and `Action::FormatArguments` on one tool
  with one policy, asserting the `access` field is present and equal in both.

Predates `access.env`: `access.fs` has had the same gap since `ab94ec0a` (#727).