Summary

• Problem: Gateway approval list and resolve paths did not consistently apply the requester metadata already stored on approval records.
• Why it matters: Approval records should only be visible and resolvable through the matching requester identity when that identity is available.
• What changed: Approval ID lookup now accepts a record filter, shared approval resolution checks caller visibility, exec/plugin list handlers filter pending records, and plugin approval requests stamp requester metadata.
• What did NOT change (scope boundary): No new permissions, transport, config, or network behavior was added.

AI-assisted: Yes.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Related: N/A
• This PR addresses a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: Approval list, get, and resolve paths now use requester metadata when deciding whether a caller can see or act on a pending approval.
• Real environment tested: Not run against a live gateway in this branch preparation.
• Exact steps or command run after this patch: Lightweight TypeScript transpile parse over the touched source and test files.
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output): transpile parse ok
• Observed result after fix: The edited TypeScript files parsed successfully.
• What was not tested: Full test suite, package-manager checks, and live gateway behavior.
• Before evidence (optional but encouraged): N/A

Root Cause (if applicable)

• Root cause: Approval ID lookup and shared resolution accepted matching IDs without applying stored requester metadata, and plugin approval records were not stamping that metadata.
• Missing detection / guardrail: Regression coverage did not assert that list and resolve paths ignore records owned by a different caller, including prefix-based ID matches.
• Contributing context (if known): Exec approval creation already stored requester metadata, but the shared resolver did not consume it.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/gateway/server-methods/server-methods.test.ts, src/gateway/server-methods/plugin-approval.test.ts
• Scenario the test should lock in: A caller only sees and resolves approvals matching its requester metadata; hidden records are treated as unknown, including full-ID and shared-prefix resolution attempts.
• Why this is the smallest reliable guardrail: The affected behavior lives in gateway server-method handlers and shared approval resolution helpers, so handler-level tests cover the contract without requiring a full gateway process.
• Existing test that already covers this (if any): Existing approval list/resolve tests covered successful behavior but not ownership filtering.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Approval list, get, and resolve calls now hide records bound to another requester identity. Mismatched approval IDs are reported the same way as unknown or expired IDs.

Diagram (if applicable)

Before:
[caller approval request] -> [global pending records] -> [list/resolve by id or prefix]

After:
[caller approval request] -> [pending records + requester metadata] -> [caller-visible lookup] -> [list/resolve or not found]

Security Impact (required)

• New permissions/capabilities? (Yes/No): No
• Secrets/tokens handling changed? (Yes/No): No
• New/changed network calls? (Yes/No): No
• Command/tool execution surface changed? (Yes/No): No
• Data access scope changed? (Yes/No): Yes
• If any Yes, explain risk + mitigation: Approval record visibility and resolution are narrowed to matching requester metadata when present. Legacy unbound records remain accessible to avoid breaking records without metadata, and regression tests cover both exec and plugin approval paths.

Repro + Verification

Environment

• OS: Not live-tested
• Runtime/container: Node/TypeScript parse check only
• Model/provider: N/A
• Integration/channel (if any): Gateway approval RPC handlers
• Relevant config (redacted): N/A

Steps

1. Create pending exec/plugin approval records with different requester metadata.
2. List approvals as one requester.
3. Resolve approval IDs and shared prefixes as matching and non-matching requesters.

Expected

• Matching requester can list and resolve its own approval records.
• Non-matching requester cannot list or resolve another requester’s records.
• Prefix lookup only considers visible records.

Actual

• Regression tests were added for those scenarios.
• Lightweight TypeScript transpile parse over touched files completed successfully.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Evidence snippet: transpile parse ok

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: Reviewed the modified approval lookup, list, get, resolve, and plugin request creation paths for requester metadata flow.
• Edge cases checked: Full-ID mismatch, prefix matching with hidden records, plugin approval metadata stamping, and legacy unbound record fallback.
• What you did not verify: Full repo test suite, package-manager checks, and live gateway behavior.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No): Yes
• Config/env changes? (Yes/No): No
• Migration needed? (Yes/No): No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: Some workflows with requester metadata but no matching caller identity could stop seeing or resolving those approval records.
  • Mitigation: Matching falls back from device ID to connection ID to client ID, and records without requester metadata remain visible for compatibility.