fix(tui): carry the region override through a resource's whole flow

[AlexanderRichey]

What

A detail page opened through project status or a harness's linked rows fetches in the region named by ?region=, but its actions are routes of their own. Enter on detail, endpoints, events, targets and the rest dropped the query, so the next screen fell back to the ambient region and failed to find a resource deployed elsewhere. The region now follows the resource through its whole flow.

How

• useRegionNavigate (src/handlers/utils.tsx) wraps useNavigate for the runtime, memory, gateway, harness and identity screens and the two wizards that navigate: string routes carry the current screen's ?region= forward, history moves (navigate(-1)) pass through untouched. The pure withRegion helper does the query-string work and leaves a route that already names a region alone, so a harness's linked rows (which link with the region from each resource's own ARN) still win over the hub's region.
• Every TUI screen and picker resolves its Core options through useCoreOpts instead of coreOptsFromCtx, so the destination honours the override wherever the flow goes: a hub's actions, the lists they open, the rows those lists forward to, the JSON views, invoke/shell/exec, and the wizards. The CLI handlers keep coreOptsFromCtx. The eval screens and pickers are switched too so the rule is uniform; nothing links to them with a region today, so it is a no-op there.
• README: one clause noting that the region follows a linked resource through its actions, lists and detail views.

Checks

• bun test src — 3164 pass. The 11 failures are all in src/io/exec.test.ts, which spawns node, not installed in the verification environment (same 11 fail on refactor).
• bun run typecheck, bun run lint:check, bun run format:check — clean.
• Rebased onto refactor at 6731091; the two conflicts with fix(tui): esc from a deep-linked harness wizard returns to the menu #2234 (the harness wizard no longer navigates, the update screen now does) resolved by hand.

Tests

• withRegion unit tests (append, join an existing query, keep an explicit region, no-op without one).
• Project status: Runtime → detail JSON refetches in the target's region; Runtime → endpoints lists in the target's region; Memory → events lists actors in the target's region.
• Hubs opened with ?region=: runtime (endpoints, then detail JSON), memory (events → actors), gateway (targets), harness (endpoints), and a harness → linked runtime → detail JSON chain, each asserting the region on the resulting Core call.

Verification in a terminal

Driven in a pseudo-terminal against a local stub replaying live-captured GetHarness responses and logging the SigV4 signing region of every request (live credentials had expired; the same setup as #2215): synthetic-linked → gateway row (a us-west-2 ARN on a us-east-1 harness) → targets listed targets with the stub signing for us-west-2; MyPDXHarness-rhkXkAE1IS opened with --region us-west-2 → runtime row → detail and endpoints fetched the JSON and the endpoint list in us-west-2. Before the change the second request in each pair signed for the ambient region.

🤖 Generated with Claude Code

https://claude.ai/code/session_016KnHdxcPYTnQiDY7Y1PY6s

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-devx-automation]

AgentCore Harness Review

Verdict: Looks good

Nice, focused fix. useRegionNavigate + withRegion is a clean way to keep the region override flowing through a resource's forward routes while leaving navigate(-1) untouched, and the change is exercised end‑to‑end (harness hub, memory hub, runtime hub, project status) rather than through hand‑mocked router internals. Options are correctly forwarded on the string‑route path, withRegion respects a route that already names a region, and the useCoreOpts/useRegionNavigate split is applied consistently on every path that's reachable via a ?region= link (project‑status detail routes and the harness linked resources).

Two small, non‑blocking observations:

• src/handlers/harness/get/screen.tsx:261 builds the region query manually (${link.route}?region=${encodeURIComponent(region)}) instead of going through withRegion. Same result today, but the helper exists — worth threading through so there's one place that knows the query‑string shape.
• The eval get screens (e.g. src/handlers/eval/dataset/get/screen.tsx, .../evaluator/get/screen.tsx, etc.) were switched to useCoreOpts but still use plain useNavigate for their JSON action. Nothing currently links to these routes with ?region=, so it's a latent inconsistency rather than a live bug — but if a future linked view ever forwards to one of them, the JSON action will silently fetch in the ambient region. Cheap to pre‑empt by using useRegionNavigate in those screens too.

Neither of those needs to block this PR.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.02%. Comparing base (6731091) to head (a3a4c5d).
⚠️ Report is 2 commits behind head on refactor.

Additional details and impacted files

@@            Coverage Diff            @@
##           refactor    #2239   +/-   ##
=========================================
  Coverage     97.02%   97.02%           
=========================================
  Files           564      564           
  Lines         39233    39260   +27     
=========================================
+ Hits          38064    38092   +28     
+ Misses         1169     1168    -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.