@polygraph/codex-plugin 0.4.38 → 0.4.40

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (6) hide show
  1. package/.codex-plugin/plugin.json +1 -1
  2. package/agents/polygraph-delegate-subagent.toml +16 -17
  3. package/package.json +1 -1
  4. package/skills/await-polygraph-ci/SKILL.md +13 -3
  5. package/skills/get-latest-ci/SKILL.md +1 -0
  6. package/skills/polygraph/SKILL.md +40 -8
package/.codex-plugin/plugin.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "polygraph",
3
- "version": "0.4.38",
3
+ "version": "0.4.40",
4
4
  "description": "AI agent skills and subagents for Polygraph sessions, repository context, and coordination",
5
5
  "author": {
6
6
  "name": "Narwhal Technologies Inc",
package/agents/polygraph-delegate-subagent.toml CHANGED
@@ -37,22 +37,21 @@ spawn_agent(
37
37
 
38
38
  The call returns immediately — the child agent runs asynchronously.
39
39
 
40
- **Backoff schedule for polling:**
40
+ **Polling with long-poll waits:**
41
41
 
42
- | Poll Attempt | Wait Before Poll |
43
- | ------------ | ---------------- |
44
- | 1st | Immediately |
45
- | 2nd | 10 seconds |
46
- | 3rd | 30 seconds |
47
- | 4th+ | 60 seconds (cap) |
48
-
49
- Use `sleep` in Bash between polls — this is mandatory, not aspirational. Without it you will hammer `show_agent` every 2-3s, which both wastes calls and floods your own context with repeated polling output. Always run sleep in the **foreground** (never background).
42
+ Call `show_agent` in a loop, passing `waitForTransitionMs: 50000` on every call:
50
43
 
51
44
  ```
52
- sleep 60 # between 4th+ polls
45
+ show_agent(
46
+ sessionId: "<sessionId>",
47
+ repo: "<repo>",
48
+ waitForTransitionMs: 50000
49
+ )
53
50
  ```
54
51
 
55
- ## Polling the children (multi-turn + input-required)
52
+ Each call blocks up to ~50 seconds and resolves within ~1 second of a state change. It returns immediately if the child is already terminal, `input-required`, or `permission-required`. Call it back-to-back in a loop.
53
+
54
+ ## Polling the child (multi-turn + input-required)
56
55
 
57
56
  After calling `spawn_agent`, parse the structured JSON response:
58
57
 
@@ -60,9 +59,9 @@ After calling `spawn_agent`, parse the structured JSON response:
60
59
  { "taskId": "…", "message": "…", "status": "delegated" }
61
60
  ```
62
61
 
63
- Then poll `show_agent` on a backoff cadence. **Do not pass a `tail` argument** — the tool's default is sized for status polling. Only set `tail` if you have a specific reason (e.g., the default truncated output you actually need to inspect, or you are hunting for an earlier failure that scrolled off). Never ratchet `tail` upward across polls; that is what causes the polling loop to flood your context window.
62
+ Then poll `show_agent` in a loop with `waitForTransitionMs: 50000`. **Do not pass a `tail` argument** — the tool's default is sized for status polling. Only set `tail` if you have a specific reason (e.g., the default truncated output you actually need to inspect, or you are hunting for an earlier failure that scrolled off). Never ratchet `tail` upward across polls; that is what causes the polling loop to flood your context window.
64
63
 
65
- For each child in the response (field: `children[]`), inspect:
64
+ The response's `children[]` array has a single entry — the child for your repo. On it, inspect:
66
65
 
67
66
  - `child.status` — an AcpRunStatus value: one of `'created'`, `'in-progress'`, `'input-required'`, `'permission-required'`, `'completed'`, `'failed'`, `'cancelled'` (British double-L on `'cancelled'`). Note `'permission-required'` and `'input-required'` are DIFFERENT states handled by different cases below — do not conflate them.
68
67
  - `child.inputRequiredQuestion` — populated only when `child.status === 'input-required'`; contains the verbatim question the child agent has asked the parent.
@@ -71,7 +70,7 @@ For each child in the response (field: `children[]`), inspect:
71
70
 
72
71
  State machine:
73
72
 
74
- 1. `child.status === 'created'` or `'in-progress'` — child is still executing. Continue polling.
73
+ 1. `child.status === 'created'` or `'in-progress'` — child is still executing. Call `show_agent` (with `waitForTransitionMs: 50000`) again.
75
74
  2. `child.status === 'input-required'` — child is paused waiting for parent input:
76
75
  - Read `child.inputRequiredQuestion`.
77
76
  - Surface this question verbatim to the parent/user: "The child agent in `{child.repoFullName}` needs input: {child.inputRequiredQuestion}".
@@ -82,14 +81,14 @@ State machine:
82
81
  <!-- Claude and Codex parents handle permission gates via the native MCP elicitation dialog
83
82
  rendered by polygraph-mcp's show_agent handler. The dialog targets the parent's main
84
83
  thread, NOT this subagent. From this subagent's perspective the gate is transient: a
85
- poll may observe permission-required briefly, but the parent's pick resolves it and the
86
- next poll sees the child back in progress. Do nothing here. -->
84
+ waited show_agent call returns immediately while the gate is open, but the parent's pick
85
+ resolves it and a later poll sees the child back in progress. Do nothing here. -->
87
86
  3. `child.status === 'permission-required'` — the child opened a permission gate. **This is NOT `input-required`. Do not treat it like case 2.** The parent's native MCP elicitation dialog already renders the prompt in the parent's own UI and routes the decision back to the child through `polygraph-mcp`. Your only job is to stay out of the way and keep polling:
88
87
 
89
88
  - **Do NOT return, finish, summarize, relay, or surface this to the parent.** Do NOT describe the child as "needing input", "awaiting approval", "asking for permission", or anything that would make the parent prompt the user — the parent already has its own dialog. Returning here is the bug this case exists to prevent.
90
89
  - **Do NOT read `child.pendingPermission` as a question to answer or forward.** It is for inspection/logging only; it is not your input prompt.
91
90
  - **Do NOT call any tool** (`spawn_agent`, `stop_agent`, `allow_agent`, `deny_agent`) to resolve it.
92
- - Treat `permission-required` **exactly like `in-progress`**: this is a transient state. **Sleep through the backoff and resume polling** — no other action. The next poll observes the child back in `in-progress` (then `completed`), or `failed` / `cancelled` if the user denied or dismissed. Only at a terminal state do you return, per the cases below.
91
+ - Treat `permission-required` **like `in-progress`**: just call `show_agent` (with `waitForTransitionMs`) again — the parent's dialog resolves it. Only at a terminal state do you return, per the cases below.
93
92
 
94
93
  4. `child.status === 'completed'` — child finished successfully. Read `child.lastOutputLines` for the most recent log tail and report outcome.
95
94
  5. `child.status === 'failed'` — child failed. Read `child.lastOutputLines` for failure context and report the error.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@polygraph/codex-plugin",
3
- "version": "0.4.38",
3
+ "version": "0.4.40",
4
4
  "description": "AI agent skills and subagents for Polygraph sessions, repository context, and coordination",
5
5
  "license": "UNLICENSED",
6
6
  "private": false,
package/skills/await-polygraph-ci/SKILL.md CHANGED
@@ -20,6 +20,8 @@ show_session(sessionId: "<session-id>")
20
20
 
21
21
  It returns the full session, including `repositories[]` (for repo display names) and `pullRequests[]`. Each `pullRequests[]` entry has `id`, `repositoryId`, `url`, `branch`, `status` (PR status: `DRAFT` / `OPEN` / `MERGED` / `CLOSED`), and a `ci` object — **`ci` may be absent if the PR has no CI**. When present, `ci` has `status`, `cipeUrl` (non-null ⇒ CIPE; null + `externalCIRuns` ⇒ external CI), `completedAt`, `selfHealingStatus`, and `externalCIRuns[]` (each with `runId`, `name`, `status`, `conclusion`, `url`, and `jobs[]`). Always read `ci` defensively (`pr.ci?.…`).
22
22
 
23
+ **`cipeUrl` is a human-facing web link, NOT a data source.** It points at the Nx Cloud web app, which requires browser authentication and returns no machine-readable data. Never fetch, curl, WebFetch, or poll `cipeUrl` (or any other Nx Cloud URL) directly. CI *status* comes only from polling `show_session`; CIPE *details* (failed tasks, logs, self-healing) come only from the Nx MCP `ci_information` tool. The only thing to do with `cipeUrl` is display it to the user so they can open it in a browser.
24
+
23
25
  ## Prerequisite: Nx MCP server (CIPE deep-dive + self-healing)
24
26
 
25
27
  CIPE failure investigation (`ci_information`) and applying/rejecting self-healing fixes (`update_self_healing_fix`) are **not** polygraph-mcp tools — they are provided by the **Nx MCP server** (`mcp__plugin_nx_nx-mcp`). Before relying on the Phase 4 CIPE deep-dive or the Phase 5 self-healing actions, install the Nx MCP server and verify it is available.
@@ -29,7 +31,14 @@ If the Nx MCP server is **not** available, this skill can still:
29
31
  - Monitor CI to a terminal state (Phases 1–3) via `show_session`, and
30
32
  - Download and inspect **external-CI** job logs via `get_ci_logs` (a polygraph-mcp tool).
31
33
 
32
- But it **cannot** perform CIPE deep-dives (`ci_information`) or apply self-healing fixes (`update_self_healing_fix`) without the Nx MCP server. If nx-mcp is missing, state this limitation to the user explicitly.
34
+ But it **cannot** perform CIPE deep-dives (`ci_information`) or apply self-healing fixes (`update_self_healing_fix`) without the Nx MCP server. Do NOT compensate by fetching or scraping `cipeUrl` — there is no HTTP fallback for CIPE data; the Nx MCP server is the only programmatic access.
35
+
36
+ If nx-mcp is missing, don't just report the limitation — tell the user how to install it:
37
+
38
+ - In an Nx workspace, run `nx configure-ai-agents` — it sets up the Nx MCP server (and Nx agent skills) for their AI tools, or
39
+ - Add the server manually as a stdio MCP server: `npx nx-mcp@latest` (see https://github.com/nrwl/nx-ai-agents-config for details).
40
+
41
+ MCP servers load at session start, so the user must restart the agent session after installing before the deep-dive and self-healing actions become available.
33
42
 
34
43
  ## Phase 1: Session Setup
35
44
 
@@ -125,7 +134,7 @@ Include self-healing status for any repo that has one.
125
134
 
126
135
  For each repo with `ciStatus: FAILED`, branch on the PR's `ci` object from `show_session` (`pullRequests[]`):
127
136
 
128
- - **If `pr.ci.cipeUrl` is non-null** → CIPE is authoritative. Delegate investigation using the Nx MCP `ci_information` tool (requires the Nx MCP server — see the prerequisite note above; if nx-mcp is unavailable, report the CIPE URL but note the deep-dive can't run).
137
+ - **If `pr.ci.cipeUrl` is non-null** → CIPE is authoritative. Delegate investigation using the Nx MCP `ci_information` tool (requires the Nx MCP server — see the prerequisite note above; if nx-mcp is unavailable, report the CIPE URL to the user, offer the install steps from the prerequisite section, and do NOT fetch the URL as a substitute).
129
138
  - **If `pr.ci.cipeUrl` is null but `pr.ci.externalCIRuns` exists** → external CI only. Examine failed jobs from `pr.ci.externalCIRuns[].jobs` and use `get_ci_logs(sessionId, repositoryId, jobId)` (a polygraph-mcp tool) for log retrieval, passing `pr.repositoryId` and the failed job's `jobId` straight from the same PR object.
130
139
 
131
140
  **Codex subagent wrapper:** Use `polygraph-delegate-subagent` to keep the Polygraph MCP `spawn_agent` / `show_agent` polling loop out of the main conversation. For each failed repo, launch a Codex `spawn_agent` with `agent_type: "polygraph-delegate-subagent"` and instructions to perform steps 2-4 below for that repo, then collect completed summaries with `wait_agent` when the main flow needs them. In the steps below, `spawn_agent` and `show_agent` refer to the Polygraph MCP tools that belong inside the Codex subagent.
@@ -181,7 +190,7 @@ For each repo with `ciStatus: FAILED`, branch on the PR's `ci` object from `show
181
190
  2. Identify cross-repo dependency issues (e.g., shared-lib build failure blocking frontend)
182
191
  3. Suggest fix order based on dependency graph (upstream repos first)
183
192
  4. Present next actions to the user based on self-healing status:
184
- - If any repo has `selfHealingStatus` with an available fix → offer to **apply self-healing** via `update_self_healing_fix(action: "APPLY")` or **reject** it. `update_self_healing_fix` is an **Nx MCP** tool (`mcp__plugin_nx_nx-mcp`) — it requires the Nx MCP server. If nx-mcp is unavailable, report that a fix is available but cannot be applied from here.
193
+ - If any repo has `selfHealingStatus` with an available fix → offer to **apply self-healing** via `update_self_healing_fix(action: "APPLY")` or **reject** it. `update_self_healing_fix` is an **Nx MCP** tool (`mcp__plugin_nx_nx-mcp`) — it requires the Nx MCP server. If nx-mcp is unavailable, report that a fix is available but cannot be applied from here, and offer the install steps from the prerequisite section.
185
194
  - If self-healing was already applied → offer to **resume monitoring** to watch the re-triggered CI
186
195
  - **Delegate fixes**: use Polygraph to send fix instructions to child agents (for repos without self-healing or where self-healing was rejected/failed)
187
196
  - **Get more details**: drill into a specific repo's failure
@@ -191,6 +200,7 @@ For each repo with `ciStatus: FAILED`, branch on the PR's `ci` object from `show
191
200
 
192
201
  - This skill does NOT push code directly. The only write action it may take is applying/rejecting a self-healing fix via `update_self_healing_fix`, an **Nx MCP** tool that performs an Nx Cloud operation (not a local code change) and requires the Nx MCP server.
193
202
  - Both `ci_information` and `update_self_healing_fix` are **Nx MCP** tools (`mcp__plugin_nx_nx-mcp`), not polygraph-mcp tools. Their responses include a `hints` array with contextual guidance (e.g., disclaimers about which CI Attempt was retrieved). Always check and surface non-empty hints.
203
+ - `cipeUrl` is a browser link for the user — never fetch, curl, WebFetch, or poll it (in the main agent or in child agents). CIPE data is only available via the Nx MCP `ci_information` tool.
194
204
  - All heavy CI data inspection happens in child agents via `spawn_agent` to keep this context window clean.
195
205
 
196
206
  - On Codex, the delegate-and-poll loop should run inside `polygraph-delegate-subagent`, and the main conversation should use `wait_agent` only when it needs to collect results.
package/skills/get-latest-ci/SKILL.md CHANGED
@@ -151,6 +151,7 @@ When `cipeStatus == 'FAILED'` AND `failedTaskIds` is empty AND `selfHealingStatu
151
151
  ## Important
152
152
 
153
153
  - This skill is **read-only**. Do NOT apply fixes, push code, or modify anything.
154
+ - `cipeUrl` and `shortLink` are human-facing web links — include them in the output for the user to open in a browser, but never fetch, curl, or poll them yourself. All CIPE data comes from the Nx MCP `ci_information` tool.
154
155
 
155
156
  - Always delegate the MCP call to a Codex built-in subagent. Do NOT call ci_information yourself in the main conversation.
156
157
 
package/skills/polygraph/SKILL.md CHANGED
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: polygraph
3
- description: Guidance for working with Polygraph sessions, shared/resumable agent context, repository graph visibility, linked PR/CI state, and cross-repo expansion when needed. Use when starting, joining, resuming, inspecting, or sharing a Polygraph session; handing off progress; discovering related repositories; coordinating changes/branches/PRs across repos; delegating tasks to child agents in different repos; or checking CI status and logs. TRIGGER when user mentions "polygraph", resuming or sharing a session, "other repos", "other repositories", "who uses this", "what uses this", "cross-repo", "multi-repo", "consuming this API/endpoint", "dependent repositories", or asks about what other repos are doing with shared code/APIs/endpoints.
3
+ description: Guidance for working with Polygraph sessions, shared/resumable agent context, repository graph visibility, linked PR/CI state, and cross-repo expansion when needed. Use when starting, joining, resuming, inspecting, or sharing a Polygraph session; handing off progress; discovering related repositories; coordinating changes/branches/PRs across repos; delegating tasks to child agents in different repos; checking CI status and logs; fetching missing git history in a shallow session clone; or tracing a commit or line of code back to the session that produced it. TRIGGER when user mentions "polygraph", resuming or sharing a session, "other repos", "other repositories", "who uses this", "what uses this", "cross-repo", "multi-repo", "consuming this API/endpoint", "dependent repositories", asks about what other repos are doing with shared code/APIs/endpoints, or asks about a "commit sha", "session behind this commit", "which session changed this line", "find session by sha", "git blame", "shallow clone", "missing commit", "bad object", "unshallow", "fetch history".
4
4
 
5
5
  ---
6
6
 
@@ -56,7 +56,7 @@ Polygraph functionality is available via both MCP tools and CLI commands. Use wh
56
56
  | `list_repos` | `polygraph repo list` | Discover candidate repositories. Candidate entries do not include repository descriptions; use `semanticQuery` for natural-language discovery. |
57
57
  | `start_session` | `polygraph session start --repo <ids>` | Initialize a Polygraph session with selected repositories |
58
58
  | `spawn_agent` | — | Start a new child task or send a follow-up to an active task in another repository. Input: `{ sessionId, repo, instruction, context? }`. Output: `{ taskId, message, status: 'delegated' }`. Follow-up routing is automatic: if the repo already has an active child task, the instruction is delivered to it as a follow-up message; otherwise a new child run starts. A repo has at most one active child at a time. A session resume or reconstruction is read-only context restoration; after resuming, do not use `spawn_agent` to continue changes unless the user explicitly asks for changes. |
59
- | `show_agent` | — | Poll flat per-child status for the session. Output: `{ children: PolygraphChildStatusItem[] }` where each item exposes `repositoryId`, `repoFullName`, `status`, `lastOutputLines`, `durationMs`, `instruction`, `agentType?`, `inputRequiredQuestion?`. `status` is an AcpRunStatus: `'created' \| 'in-progress' \| 'input-required' \| 'permission-required' \| 'completed' \| 'failed' \| 'cancelled'` (British double-L on `'cancelled'`). `inputRequiredQuestion` is populated only when `status === 'input-required'`. |
59
+ | `show_agent` | — | Poll the status of the specified repo's child (`repo` is required — one call covers one repo). Output: `{ children: PolygraphChildStatusItem[] }` with a single entry for that repo; the item exposes `repositoryId`, `repoFullName`, `status`, `lastOutputLines`, `durationMs`, `instruction`, `agentType?`, `inputRequiredQuestion?`. `status` is an AcpRunStatus: `'created' \| 'in-progress' \| 'input-required' \| 'permission-required' \| 'completed' \| 'failed' \| 'cancelled'` (British double-L on `'cancelled'`). `inputRequiredQuestion` is populated only when `status === 'input-required'`. |
60
60
  | `stop_agent` | — | Cancel an in-progress child. Output: `{ taskId, state: 'cancelled', sessionPreserved: true, output, message }`. Because `sessionPreserved: true`, the preserved agent session can be restored later for context, but resume must wait for explicit user instructions before making changes. |
61
61
  | `push_branch` | — | Push a local git branch to the remote repository. For the repo you are in, this pushes from your current checkout. Requires a session description. |
62
62
  | `create_pr` | — | Create draft PRs with session metadata linking related PRs |
@@ -68,9 +68,11 @@ Polygraph functionality is available via both MCP tools and CLI commands. Use wh
68
68
  | `add_repo` | — | Add repositories to a running Polygraph session. For explicit refs, pass the refs directly and skip `list_repos`. |
69
69
  | `archive_session` | `polygraph session archive <id>` | Archive a session, hiding it from active lists (it can still be resumed) |
70
70
  | `get_ci_logs` | — | Retrieve full plain-text log for a specific CI job |
71
+ | `git_fetch` | `polygraph git fetch` | Fetch additional git history for a shallow session clone. Use when git operations fail with "bad object" or missing-commit errors; by default fetches the full history of the default branch. Input: `{ sessionId, repo, depth?, refs? }`. See "Fetching Git History for Shallow Clones". |
71
72
  | `login` | `polygraph auth login [--token]` | Authenticate with Polygraph (use `--token` for headless/CI) |
72
73
  | `logout` | `polygraph auth logout` | Log out of Polygraph |
73
74
  | `list_sessions` | `polygraph session list` | List sessions. By default only active sessions created by the current git user; pass `recommendedFilters: false` for all sessions. |
75
+ | `search_sessions` | `polygraph session search` | Find sessions by free-text `query` OR by commit `sha` — pass EXACTLY ONE of the two (they are mutually exclusive). `sha` (CLI: `--sha <sha>`) is an exact lookup of the session(s) linked to a commit, full or partial, 7-40 hex chars; it returns matching sessions newest first, org-scoped, and explicit sessions only (implicit sessions are never returned). Supports `--json` and `--limit` (1-50). See "Finding the Session Behind a Commit or Line". |
74
76
  | `list_accounts` | `polygraph account list` | List available organizations |
75
77
  | `select_account` | `polygraph account select` | Select the organization that future commands run against |
76
78
  | `whoami` | `polygraph whoami` | Show current auth status and org |
@@ -106,7 +108,7 @@ The delegate/monitor/stop steps apply only when working across repos. A single-r
106
108
  0. **Initialize or join Polygraph session** - If you were spawned inside an existing session (the startup banner names a session ID), reuse it. Call `show_session` first; if it already has repos and the user did not ask to add more, you're done. If the user asks to add exact repo refs, call `add_repo` directly with those refs and skip candidate discovery. If the session has no repos and no exact refs were provided, launch the `polygraph-init-subagent` with that `sessionId` so it discovers candidates and uses `add_repo` (NOT `start_session`). Only when there is no session ID at all should the init subagent create a new session.
107
109
  1. **Delegate work to each repo** - Use the `polygraph-delegate-subagent` to start child agents in other repositories. Delegate only to *other* repos — never to the repo you are in; work on it directly (your regular subagents are fine for local work — only Polygraph delegation is reserved for other repos). Parallel delegation across repos is encouraged, but only one active child per repo. Choose the Simple (fire-and-forget) or Multi-turn (interactive) pattern described below based on whether the child may need clarification.
108
110
 
109
- 4. **Monitor child agents** - Use `show_agent` to poll progress and read the flat `children[]` array for each child's `status` and `lastOutputLines`.
111
+ 4. **Monitor child agents** - Use `show_agent` to poll one repo's child (`repo` is required) and read its `status` and `lastOutputLines` from the single-entry `children[]` array.
110
112
  5. **Stop child agents** (if needed) - Use `stop_agent` to cancel an in-progress child agent. The underlying agent session is preserved for later read-only context restoration; after a resume, wait for explicit user instructions before making changes.
111
113
  6. **Push branches** - Use `push_branch` after making commits. A required `description` must follow the Session Description Policy.
112
114
  7. **Update session description** - Use `update_session` to update the session description; must follow the Session Description Policy. Independent of PR creation or mark-ready.
@@ -224,6 +226,32 @@ Description:
224
226
  Inspect the PR commits/diff and investigate the requested behavior. Report findings with file paths and concrete evidence.
225
227
  ```
226
228
 
229
+ ### Finding the Session Behind a Commit or Line
230
+
231
+ Use this workflow when the user asks which Polygraph session produced, is behind, or changed a particular commit — or a particular line of code.
232
+
233
+ **Given a commit sha.** When the user names a sha, or asks what session is behind a commit, resolve it with `search_sessions` using the `sha` parameter (CLI: `polygraph session search --sha <sha>`):
234
+
235
+ - Pass **exactly one** of `query` or `sha` — they are mutually exclusive.
236
+ - `sha` accepts a full or partial sha, 7-40 hex chars.
237
+ - The lookup is exact and one-shot: it returns the session(s) linked to that commit, newest first, scoped to the current org, and only explicit sessions.
238
+
239
+ ```
240
+ search_sessions(sha: "a1b2c3d")
241
+ # CLI equivalent:
242
+ polygraph session search --sha a1b2c3d
243
+ ```
244
+
245
+ **Given a line number.** There is no line-number lookup — a line MUST first be resolved to a commit sha with `git blame`, then that sha is fed into the sha lookup:
246
+
247
+ 1. `git blame -L <line>,<line> -- <file>` to get the commit that last touched the line.
248
+ 2. Pass that sha to `search_sessions(sha: ...)` (or `polygraph session search --sha <sha>`).
249
+
250
+ **Reading the results.**
251
+
252
+ - Multiple sessions may match a sha. They come back newest first — pick the most relevant one and report the others if they matter.
253
+ - **A "no match" result does NOT prove the commit had no work behind it.** Not every commit is linked to an explicit session: commits pushed directly (rather than via an ingested PR) and gaps in ingestion metadata mean the sha may simply not be recorded, and implicit sessions are never returned. Report "no linked session found for that sha" — never assert that no work exists behind the commit.
254
+
227
255
  ## Simple tasks (fire-and-forget)
228
256
 
229
257
  Use this pattern when the task is well-defined and the child is not expected to need clarification. It is a single-round delegation: kick it off, poll until terminal, then push branch + create PR.
@@ -242,13 +270,13 @@ spawn_agent(
242
270
  - instruction: "<the task instruction>"
243
271
  - context: "<optional context>"
244
272
 
245
- Call the Polygraph MCP spawn_agent for the repo, then poll show_agent on backoff until terminal. Return a structured summary with repo, status, session ID, and result text.
273
+ Call the Polygraph MCP spawn_agent for the repo, then poll show_agent via chained waitForTransitionMs long-poll calls until terminal. Return a structured summary with repo, status, session ID, and result text.
246
274
  """
247
275
  )
248
276
  ```
249
277
 
250
278
  2. Delegate to multiple repos in parallel by launching multiple `polygraph-delegate-subagent` instances before waiting for results — one delegation per repo at a time.
251
- 3. For each child, the subagent watches `child.status` in the flat `children[]` response and exits when it sees a terminal status — typically `'completed'` or `'failed'` (and `'cancelled'` if it was stopped).
279
+ 3. The subagent watches `child.status` on the single `children[]` entry for its repo and exits when it sees a terminal status — typically `'completed'` or `'failed'` (and `'cancelled'` if it was stopped).
252
280
  4. Collect completed results with `wait_agent` when the main flow needs them, then continue to `push_branch` + `create_pr`.
253
281
 
254
282
  In rare cases where you need to check the raw child agent status directly (e.g., debugging a stuck subagent), you may call the Polygraph MCP `show_agent` as a one-off tool call. Do NOT use this for regular polling — that belongs inside `polygraph-delegate-subagent`.
@@ -265,7 +293,7 @@ Use this pattern when the child may need clarification, the task is exploratory,
265
293
  { "taskId": "…", "message": "…", "status": "delegated" }
266
294
  ```
267
295
 
268
- 2. Poll `show_agent`. The response shape is `{ children: PolygraphChildStatusItem[] }`. For each child, inspect:
296
+ 2. Poll `show_agent` via chained `waitForTransitionMs` long-poll calls (`repo` is required). The response shape is `{ children: PolygraphChildStatusItem[] }` with a single entry for that repo. On it, inspect:
269
297
 
270
298
  - `child.status` — one of `'created'`, `'in-progress'`, `'input-required'`, `'permission-required'`, `'completed'`, `'failed'`, `'cancelled'` (British double-L on `'cancelled'`).
271
299
  - `child.inputRequiredQuestion` — populated only when `child.status === 'input-required'`.
@@ -440,7 +468,7 @@ Check the details of a session using `show_session` or `polygraph session show -
440
468
  - `relatedPRs`: Array of related PR URLs across repos
441
469
  - `session.ciStatus`: CI pipeline status keyed by PR ID, each containing:
442
470
  - `status`: One of `SUCCEEDED`, `FAILED`, `IN_PROGRESS`, `NOT_STARTED` (null if no CIPE and no external CI)
443
- - `cipeUrl`: URL to the CI pipeline execution details (null if no CIPE)
471
+ - `cipeUrl`: URL to the CI pipeline execution details (null if no CIPE). This is a human-facing Nx Cloud web link — display it to the user, but never fetch, curl, or poll it directly; CIPE data is only accessible programmatically via the Nx MCP `ci_information` tool
444
472
  - `completedAt`: Epoch millis timestamp, set only when the CIPE has completed (null otherwise)
445
473
  - `selfHealingStatus`: The self-healing fix status string from Nx Cloud's AI fix feature (null if no AI fix exists)
446
474
  - `externalCIRuns`: Array of external CI runs (present when no CIPE but external CI data exists, e.g., GitHub Actions). Each run contains:
@@ -610,7 +638,7 @@ archive_session(
610
638
 
611
639
  Use `get_ci_logs` to retrieve the full plain-text log for a specific CI job. This is the drill-in tool for investigating CI failures after identifying a failed job from the session's CI status.
612
640
 
613
- **ONLY use this tool when NO CIPE (CI Pipeline Execution) exists for the PR.** When a CIPE exists (`ciStatus[prId].cipeUrl` is non-null), logs and failure data are available through the CIPE system (Nx Cloud) via `ci_information` — do NOT call `get_ci_logs`. This tool is specifically for PRs where only external CI runs exist (e.g., GitHub Actions runs without an Nx Cloud CIPE).
641
+ **ONLY use this tool when NO CIPE (CI Pipeline Execution) exists for the PR.** When a CIPE exists (`ciStatus[prId].cipeUrl` is non-null), logs and failure data are available through the CIPE system (Nx Cloud) via the Nx MCP `ci_information` tool — do NOT call `get_ci_logs`, and do NOT fetch or poll the `cipeUrl` over HTTP (it is a browser link for the user, not an API). This tool is specifically for PRs where only external CI runs exist (e.g., GitHub Actions runs without an Nx Cloud CIPE).
614
642
 
615
643
  **Parameters:**
616
644
 
@@ -645,6 +673,10 @@ get_ci_logs(
645
673
 
646
674
  **Important:** Logs can be large (100KB+). Only fetch logs for failed or relevant jobs, and read only the sections you need.
647
675
 
676
+ ### Fetching Git History for Shallow Clones
677
+
678
+ Session repos are shallow (`--depth 1`) clones and plain `git fetch --unshallow` fails on private repos (the clone-time credential is not retained). When git fails on missing history (`bad object` from `git revert`, `git log`, `git blame`, etc.), call `git_fetch({ sessionId, repo })` (CLI: `polygraph git fetch <repo> --session <id> --json`), then retry. Defaults fetch the default branch's full history; pass `depth` for a bounded fetch or `refs` for extra branches. Safe to call redundantly (`alreadyComplete: true`).
679
+
648
680
  ### Update Session Description
649
681
 
650
682
  Use this when the user asks to summarize progress, update the session description, or capture the current state.