Jira support currently takes two different paths. The triage harness declares providers/jira-ro.yaml, but also expands the real JIRA_TOKEN into env.sandbox; the code harness keeps the token on the runner and prefetches the Jira issue into .issue-context.json.
Could we converge both agents on OpenShell provider-backed Jira access? The reason to do this is to let the agents query Jira when they need to while keeping the credential boundary at the gateway: the real API token should never appear in a sandbox environment variable, file, process argument, log, or generated context. The sandbox should only receive the provider's opaque placeholder, which OpenShell replaces at the HTTP layer.
Acceptance criteria:
- The Jira overlays for both triage and code attach the appropriate Jira provider and OpenShell profile.
JIRA_TOKEN is not copied or expanded into either sandbox through env.sandbox, host_files, or generated issue context. Only an OpenShell provider placeholder is available to sandboxed Jira clients.- The code agent reads Jira source work items through provider-backed Jira API access instead of runner-side credential use and
.issue-context.json prefetching.
- Runner-side triage mutations can continue to use the real credential where needed, but the agent's sandboxed Jira reads use the provider boundary.
- The Jira profiles restrict access to the required Jira Cloud hosts, HTTP methods and paths, and calling binaries. Read-only sandbox access should remain read-only.
- Jira skills and scripts continue to authenticate successfully with Jira Cloud Basic auth without assuming that the sandbox-visible token is the real secret.
- Tests verify provider/profile selection for Jira-triggered triage and code runs, verify the expected Jira behavior, and fail if the real token is present anywhere in the sandbox configuration or prepared files.
- The triage and code documentation describes provider-backed Jira authentication and the credential boundary accurately.
This would bring Jira in line with the provider-based credential delivery model in fullsend ADR 0025 while preserving the split between sandboxed reads and trusted runner-side writes.
Jira support currently takes two different paths. The triage harness declares
providers/jira-ro.yaml, but also expands the realJIRA_TOKENintoenv.sandbox; the code harness keeps the token on the runner and prefetches the Jira issue into.issue-context.json.Could we converge both agents on OpenShell provider-backed Jira access? The reason to do this is to let the agents query Jira when they need to while keeping the credential boundary at the gateway: the real API token should never appear in a sandbox environment variable, file, process argument, log, or generated context. The sandbox should only receive the provider's opaque placeholder, which OpenShell replaces at the HTTP layer.
Acceptance criteria:
JIRA_TOKENis not copied or expanded into either sandbox throughenv.sandbox,host_files, or generated issue context. Only an OpenShell provider placeholder is available to sandboxed Jira clients..issue-context.jsonprefetching.This would bring Jira in line with the provider-based credential delivery model in fullsend ADR 0025 while preserving the split between sandboxed reads and trusted runner-side writes.