feat(core): add permissions-instructions renderer (input env-context building block)

First piece of the `input` context-fragment system (the largest remaining
request-body gap). RenderPermissionsInstructions ports codex's
PermissionsInstructions fragment (permissions_instructions.rs + fragment.rs):
the developer-role `<permissions instructions>` block built from the sandbox
mode, network access, and approval policy, with the prompt texts embedded
byte-for-byte from codex's prompts/permissions/*.md and codex's append_section /
marker-wrapping semantics replicated exactly.

Unit-tested against the real codex 0.136.0 captured output: the default
`codex exec` config (read-only + network restricted + approval never) renders
byte-identically. Not yet wired into the turn input (next: environment_context
renderer + injection into the session initial history + structural differential);
tracked in docs/PARITY.md.

Author: SqlRush

internal/core/permissions_instructions.go

@@ -0,0 +1,124 @@
+package core
+
+import (
+	_ "embed"
+	"strings"
+
+	"github.com/sqlrush/codexgo/internal/protocol"
+)
+
+// This file ports codex's permissions-instructions fragment
+// (core/src/context/permissions_instructions.rs): the developer-role
+// `<permissions instructions>` message that tells the model the active sandbox
+// mode, network access, and approval policy. The prompt texts are embedded
+// byte-for-byte from codex's prompts/permissions/*.md.
+//
+// Scope: the base sandbox-mode × approval-policy matrix used by `codex exec`
+// (the request_permissions_tool wrapper, auto_review suffix, writable-roots and
+// denied-reads sections are conditional refinements tracked in docs/PARITY.md and
+// added with the full permission-profile wiring).
+
+//go:embed prompts/permissions/sandbox_mode/read_only.md
+var sandboxReadOnlyTemplate string
+
+//go:embed prompts/permissions/sandbox_mode/workspace_write.md
+var sandboxWorkspaceWriteTemplate string
+
+//go:embed prompts/permissions/sandbox_mode/danger_full_access.md
+var sandboxDangerFullAccessTemplate string
+
+//go:embed prompts/permissions/approval_policy/never.md
+var approvalNeverText string
+
+//go:embed prompts/permissions/approval_policy/unless_trusted.md
+var approvalUnlessTrustedText string
+
+//go:embed prompts/permissions/approval_policy/on_failure.md
+var approvalOnFailureText string
+
+//go:embed prompts/permissions/approval_policy/on_request.md
+var approvalOnRequestText string
+
+const (
+	permissionsStartMarker = "<permissions instructions>"
+	permissionsEndMarker   = "</permissions instructions>"
+	networkAccessKey       = "{{network_access}}"
+)
+
+// PermissionsSandboxMode is the effective filesystem sandbox mode for the prompt,
+// mirroring the Rust SandboxMode the prompt selects on (read-only /
+// workspace-write / danger-full-access).
+type PermissionsSandboxMode int
+
+const (
+	// SandboxModeReadOnly permits only reads.
+	SandboxModeReadOnly PermissionsSandboxMode = iota
+	// SandboxModeWorkspaceWrite permits writes to cwd/writable roots.
+	SandboxModeWorkspaceWrite
+	// SandboxModeDangerFullAccess disables filesystem sandboxing.
+	SandboxModeDangerFullAccess
+)
+
+// networkAccessWord renders the {{network_access}} value, matching codex's
+// kebab-case NetworkAccess Display ("restricted" / "enabled").
+func networkAccessWord(enabled bool) string {
+	if enabled {
+		return "enabled"
+	}
+	return "restricted"
+}
+
+// sandboxPromptText renders the sandbox-mode section, replacing {{network_access}}
+// in the embedded template. Mirrors Rust `sandbox_text`.
+func sandboxPromptText(mode PermissionsSandboxMode, networkEnabled bool) string {
+	var tmpl string
+	switch mode {
+	case SandboxModeDangerFullAccess:
+		tmpl = sandboxDangerFullAccessTemplate
+	case SandboxModeWorkspaceWrite:
+		tmpl = sandboxWorkspaceWriteTemplate
+	default:
+		tmpl = sandboxReadOnlyTemplate
+	}
+	return strings.ReplaceAll(tmpl, networkAccessKey, networkAccessWord(networkEnabled))
+}
+
+// approvalPromptText returns the approval-policy section for the given policy
+// kind, mirroring the base branches of Rust `approval_text` (without the
+// conditional request_permissions_tool wrapper / auto_review suffix).
+func approvalPromptText(policy protocol.AskForApprovalKind) string {
+	switch policy {
+	case protocol.AskForApprovalUnlessTrusted:
+		return approvalUnlessTrustedText
+	case protocol.AskForApprovalOnFailure:
+		return approvalOnFailureText
+	case protocol.AskForApprovalOnRequest:
+		return approvalOnRequestText
+	default: // AskForApprovalNever
+		return approvalNeverText
+	}
+}
+
+// appendPermissionsSection mirrors Rust `append_section` exactly: if the
+// accumulator does not end with a newline (an empty string included), push one,
+// then append the section. So the first section is prefixed with '\n' and
+// subsequent sections are single-newline separated.
+func appendPermissionsSection(text, section string) string {
+	if !strings.HasSuffix(text, "\n") {
+		text += "\n"
+	}
+	return text + section
+}
+
+// RenderPermissionsInstructions builds the full `<permissions instructions>`
+// developer message body for the active sandbox/network/approval settings,
+// mirroring codex's PermissionsInstructions::from_permissions + fragment render
+// (start_marker + body + end_marker, newlines carried in the body).
+func RenderPermissionsInstructions(mode PermissionsSandboxMode, networkEnabled bool, policy protocol.AskForApprovalKind) string {
+	text := appendPermissionsSection("", sandboxPromptText(mode, networkEnabled))
+	text = appendPermissionsSection(text, approvalPromptText(policy))
+	if !strings.HasSuffix(text, "\n") {
+		text += "\n"
+	}
+	return permissionsStartMarker + text + permissionsEndMarker
+}

internal/core/permissions_instructions_test.go

@@ -0,0 +1,64 @@
+package core
+
+import (
+	"strings"
+	"testing"
+
+	"github.com/sqlrush/codexgo/internal/protocol"
+)
+
+// TestRenderPermissionsInstructionsReadOnlyNever pins the exact `<permissions
+// instructions>` block codex emits for the default `codex exec` config
+// (read-only sandbox, network restricted, approval never) — captured byte-for-byte
+// from the real codex 0.136.0 binary's /responses request.
+func TestRenderPermissionsInstructionsReadOnlyNever(t *testing.T) {
+	const want = "<permissions instructions>\n" +
+		"Filesystem sandboxing defines which files can be read or written. `sandbox_mode` is `read-only`: The sandbox only permits reading files. Network access is restricted.\n" +
+		"Approval policy is currently never. Do not provide the `sandbox_permissions` for any reason, commands will be rejected.\n" +
+		"</permissions instructions>"
+
+	got := RenderPermissionsInstructions(SandboxModeReadOnly, false, protocol.AskForApprovalNever)
+	if got != want {
+		t.Errorf("permissions instructions mismatch\n want: %q\n got:  %q", want, got)
+	}
+}
+
+// TestRenderPermissionsInstructionsStructure checks the marker wrapping and
+// section ordering invariants across the sandbox modes: the body opens after the
+// start marker on its own line, the sandbox line precedes the approval line, and
+// the network word reflects the flag.
+func TestRenderPermissionsInstructionsStructure(t *testing.T) {
+	cases := []struct {
+		name        string
+		mode        PermissionsSandboxMode
+		network     bool
+		wantSandbox string
+		wantNet     string
+	}{
+		{"read-only restricted", SandboxModeReadOnly, false, "`read-only`", "restricted"},
+		{"workspace-write enabled", SandboxModeWorkspaceWrite, true, "`workspace-write`", "enabled"},
+		{"danger enabled", SandboxModeDangerFullAccess, true, "`danger-full-access`", "enabled"},
+	}
+	for _, tc := range cases {
+		t.Run(tc.name, func(t *testing.T) {
+			got := RenderPermissionsInstructions(tc.mode, tc.network, protocol.AskForApprovalNever)
+			if !strings.HasPrefix(got, permissionsStartMarker+"\n") {
+				t.Errorf("missing start marker + newline; got prefix %q", got[:min(60, len(got))])
+			}
+			if !strings.HasSuffix(got, "\n"+permissionsEndMarker) {
+				t.Errorf("missing newline + end marker; got suffix %q", got[max(0, len(got)-60):])
+			}
+			if !strings.Contains(got, tc.wantSandbox) {
+				t.Errorf("expected sandbox marker %q in %q", tc.wantSandbox, got)
+			}
+			if !strings.Contains(got, "Network access is "+tc.wantNet+".") {
+				t.Errorf("expected network %q in %q", tc.wantNet, got)
+			}
+			sandboxIdx := strings.Index(got, "Filesystem sandboxing")
+			approvalIdx := strings.Index(got, "Approval policy is currently never")
+			if sandboxIdx < 0 || approvalIdx < 0 || sandboxIdx > approvalIdx {
+				t.Errorf("sandbox section must precede approval section; got %q", got)
+			}
+		})
+	}
+}

internal/core/prompts/permissions/approval_policy/never.md

@@ -0,0 +1 @@
+Approval policy is currently never. Do not provide the `sandbox_permissions` for any reason, commands will be rejected.

internal/core/prompts/permissions/approval_policy/on_failure.md

@@ -0,0 +1 @@
+Approvals are your mechanism to get user consent to run shell commands without the sandbox. `approval_policy` is `on-failure`: The harness will allow all commands to run in the sandbox (if enabled), and failures will be escalated to the user for approval to run again without the sandbox.

internal/core/prompts/permissions/approval_policy/on_request.md

@@ -0,0 +1,57 @@
+# Escalation Requests
+
+Commands are run outside the sandbox if they are approved by the user, or match an existing rule that allows it to run unrestricted. The command string is split into independent command segments at shell control operators, including but not limited to:
+
+- Pipes: |
+- Logical operators: &&, ||
+- Command separators: ;
+- Subshell boundaries: (...), $(...)
+
+Each resulting segment is evaluated independently for sandbox restrictions and approval requirements.
+
+Example:
+
+git pull | tee output.txt
+
+This is treated as two command segments:
+
+["git", "pull"]
+
+["tee", "output.txt"]
+
+Commands that use more advanced shell features like redirection (>, >>, <), substitutions ($(...), ...), environment variables (FOO=bar), or wildcard patterns (*, ?) will not be evaluated against rules, to limit the scope of what an approved rule allows.
+
+## How to request escalation
+
+IMPORTANT: To request approval to execute a command that will require escalated privileges:
+
+- Provide the `sandbox_permissions` parameter with the value `"require_escalated"`
+- Include a short question asking the user if they want to allow the action in `justification` parameter. e.g. "Do you want to download and install dependencies for this project?"
+- Optionally suggest a `prefix_rule` - this will be shown to the user with an option to persist the rule approval for future sessions.
+
+If you run a command that is important to solving the user's query, but it fails because of sandboxing or with a likely sandbox-related network error (for example DNS/host resolution, registry/index access, or dependency download failure), rerun the command with "require_escalated". ALWAYS proceed to use the `justification` parameter - do not message the user before requesting approval for the command.
+
+## When to request escalation
+
+While commands are running inside the sandbox, here are some scenarios that will require escalation outside the sandbox:
+
+- You need to run a command that writes to a directory that requires it (e.g. running tests that write to /var)
+- You need to run a GUI app (e.g., open/xdg-open/osascript) to open browsers or files.
+- If you run a command that is important to solving the user's query, but it fails because of sandboxing or with a likely sandbox-related network error (for example DNS/host resolution, registry/index access, or dependency download failure), rerun the command with `require_escalated`. ALWAYS proceed to use the `sandbox_permissions` and `justification` parameters. do not message the user before requesting approval for the command.
+- You are about to take a potentially destructive action such as an `rm` or `git reset` that the user did not explicitly ask for.
+- Be judicious with escalating, but if completing the user's request requires it, you should do so - don't try and circumvent approvals by using other tools.
+
+## prefix_rule guidance
+
+When choosing a `prefix_rule`, request one that will allow you to fulfill similar requests from the user in the future without re-requesting escalation. It should be categorical and reasonably scoped to similar capabilities. You should rarely pass the entire command into `prefix_rule`.
+
+### Banned prefix_rules 
+Avoid requesting overly broad prefixes that the user would be ill-advised to approve. For example, do not request ["python3"], ["python", "-"], or other similar prefixes that would allow arbitrary scripting.
+NEVER provide a prefix_rule argument for destructive commands like rm.
+NEVER provide a prefix_rule if your command uses a heredoc or herestring. 
+
+### Examples
+Good examples of prefixes:
+- ["npm", "run", "dev"]
+- ["gh", "pr", "check"]
+- ["cargo", "test"]

internal/core/prompts/permissions/approval_policy/unless_trusted.md

@@ -0,0 +1 @@
+ Approvals are your mechanism to get user consent to run shell commands without the sandbox. `approval_policy` is `unless-trusted`: The harness will escalate most commands for user approval, apart from a limited allowlist of safe "read" commands.

internal/core/prompts/permissions/sandbox_mode/danger_full_access.md

@@ -0,0 +1 @@
+Filesystem sandboxing defines which files can be read or written. `sandbox_mode` is `danger-full-access`: No filesystem sandboxing - all commands are permitted. Network access is {{network_access}}.

internal/core/prompts/permissions/sandbox_mode/read_only.md

@@ -0,0 +1 @@
+Filesystem sandboxing defines which files can be read or written. `sandbox_mode` is `read-only`: The sandbox only permits reading files. Network access is {{network_access}}.

internal/core/prompts/permissions/sandbox_mode/workspace_write.md

@@ -0,0 +1 @@
+Filesystem sandboxing defines which files can be read or written. `sandbox_mode` is `workspace-write`: The sandbox permits reading files, and editing files in `cwd` and `writable_roots`. Editing files in other directories requires approval. Network access is {{network_access}}.