@pensar/apex 2.4.0 → 2.5.0-canary.2bbb0f6f

package/build/{cli-mavved45.js → cli-3ew5fs3f.js}

@@ -5,7 +5,7 @@ import {
   createReportErrorTool,
   isMemoryEnabled,
   readPlan
-} from "./cli-repbyhkk.js";
+} from "./cli-4vwnsyep.js";
 import {
   createLogger,
   hasToolCall,
@@ -13,11 +13,11 @@ import {
   init_lazyLogger,
   init_structured,
   scopedLogger
-} from "./cli-tkc598ey.js";
+} from "./cli-f47dgye3.js";
 import {
   exports_external,
   init_zod
-} from "./cli-swpbx60z.js";
+} from "./cli-avmhkjtv.js";
 
 // src/core/agents/specialized/pentest/agent.ts
 init_dist();
@@ -27,8 +27,12 @@ import { existsSync, readdirSync, readFileSync } from "node:fs";
 import { join } from "node:path";
 init_lazyLogger();
 var log = scopedLogger(() => createLogger("pentest-agent"));
-function resolvePentestAgentRole(mode = "default", role = "orchestrator") {
-  return mode === "fast-strike" ? "worker" : role;
+function resolvePentestAgentRole(mode = "default", role = "orchestrator", disableSubagents = false) {
+  if (mode === "fast-strike")
+    return "worker";
+  if (disableSubagents)
+    return "worker";
+  return role;
 }
 var ObjectiveResultSchema = exports_external.object({
   objective: exports_external.string().describe("The objective text, exactly as it was provided or a refined version"),
@@ -55,6 +59,7 @@ class TargetedPentestAgent extends OffensiveSecurityAgent {
       authConfig,
       onStepFinish,
       onCacheMetrics,
+      forwardUsageCallbacksToSpawnedAgents,
       abortSignal,
       eventBus,
       subagentId,
@@ -72,18 +77,21 @@ class TargetedPentestAgent extends OffensiveSecurityAgent {
       browserSession,
       display
     } = opts;
-    const effectiveRole = resolvePentestAgentRole(mode, role);
+    const effectiveRole = resolvePentestAgentRole(mode, role, session.config?.disableSubagents ?? false);
+    const systemScope = opts.systemScope;
     let reportedError = null;
     super({
-      system: buildPentestSystemPrompt(session, effectiveRole, mode),
+      system: buildPentestSystemPrompt(session, effectiveRole, mode, systemScope),
       prompt: buildPentestPrompt(target, objectives, session, findingsRegistry, context, environmentVariables ? Object.keys(environmentVariables) : undefined, subagentId, effectiveRole, session.credentialManager?.formatForPrompt(), grpc, mode),
       model,
       session,
       target,
       grpc,
+      systemScope,
       authConfig,
       onStepFinish,
       onCacheMetrics,
+      forwardUsageCallbacksToSpawnedAgents,
       abortSignal,
       eventBus,
       subagentId,
@@ -204,13 +212,13 @@ var SECTION_BROWSER_INTERACTION = `Browser Interaction:
 - Screenshots are cheap — prefer taking one and not needing it over skipping one and losing visibility. Do NOT attempt to conserve tokens by skipping screenshots during browser-driven testing.
 - Screenshots are automatically stored and displayed alongside your tool call logs, so each one directly improves the user's ability to follow the test in real time.`;
 var SECTION_AUTHENTICATION = `Authentication:
-- If the prompt includes an "Existing Authentication Session" section, USE those cookies/headers on every request and do NOT re-authenticate up front. If such a request returns 401/403, that provided session has expired — note it in your findings (and call report_error if it blocks all further testing). Only log in yourself (following any "Available Credentials" instructions) if that provided session expires mid-run.
+- If the prompt includes an "Existing Authentication Session" section, use those cookies/headers on requests to the origin they authorize and do NOT re-authenticate up front there. Verify them against a protected resource on your assigned origin. A 401/403 from one resource does not by itself prove authentication failure. Verify the session against a known protected or session endpoint and re-authenticate on the assigned origin only if needed. Call report_error with reason "authentication_failed" only if required authentication cannot be established and this blocks the assigned objective or all further testing; otherwise continue any reachable testing.
 - Otherwise, if the target requires authentication, log in yourself. When an "Available Credentials" section is present, follow the authentication instructions in each credential's Context exactly — use the method it describes (for example, a token/API exchange driven with execute_command or http_request) instead of defaulting to a browser login. Only fall back to driving the login flow in the browser with browser_navigate + browser_fill when the Context does not specify how to authenticate. Prefer credentialId + credentialField so secrets are resolved securely; injected credential environment variables are also available inside execute_command.
 - After a successful login, capture the resulting session credentials and reuse them for raw requests. For a browser login, call browser_get_cookies to extract the session cookies (including httpOnly ones) — pass them as the Cookie header to http_request, or as -H "Cookie: ..." / -b flags to execute_command (curl). Any worker you spawn automatically inherits a snapshot of your authenticated browser session.
 - For http_request: include the captured Cookie and any Authorization headers on every call. For execute_command (curl): include -H "Cookie: ..." and/or -H "Authorization: ..." flags.
-- If a request returns 401/403 after you logged in yourself, your captured session may have expired — re-authenticate the same way you did originally and refresh your session cookies/tokens.
-- Do NOT spin your wheels on authentication. If you have followed the credential Context instructions and still cannot authenticate, do NOT try to work around it — do NOT register a new account, self-sign-up, or fabricate credentials to authenticate. Those are not the credentials under test and only pollute results. (Registering a throwaway account is acceptable only as a disposable *target* for destructive-flow POCs per the blast-radius rungs below — never as a substitute for authenticating as the credential under test.) Make at most a couple of genuine attempts, then call report_error with reason "authentication_failed" and a specific message describing exactly what you tried and how it failed.
-- If you cannot authenticate with the available credentials, or another runtime condition blocks all testing, call report_error with a clear, specific message instead of giving up silently or documenting a non-finding.
+- If a request returns 401/403 after you logged in yourself, verify the session against a known protected or session endpoint. Re-authenticate the same way you did originally and refresh your session cookies/tokens only when that verification shows the session is missing or expired.
+- Do NOT spin your wheels on authentication. If you have followed the credential Context instructions and still cannot authenticate, do NOT try to work around it — do NOT register a new account, self-sign-up, or fabricate credentials to authenticate. Those are not the credentials under test and only pollute results. (Registering a throwaway account is acceptable only as a disposable *target* for destructive-flow POCs per the blast-radius rungs below — never as a substitute for authenticating as the credential under test.) Make at most a couple of genuine attempts. If required authentication still cannot be established and blocks the assigned objective or all further testing, call report_error with reason "authentication_failed" and a specific message describing exactly what you tried and how it failed; otherwise continue reachable testing and include the limitation in your final response.
+- If unavailable authentication or another runtime condition blocks the assigned objective or all further testing, call report_error with a clear, specific message instead of giving up silently or documenting a non-finding. Do not abort for a non-blocking limitation.
 - Build verifiable POCs, but bound the blast radius. Prove impact with the least-invasive action that still demonstrates the flaw, preferring earlier rungs:
   1. Prove a broken-authorization / privileged-role / IDOR boundary with a READ, or with a benign, reversible write to a low-impact field (e.g. your own display name). That a privileged call is accepted against an object you should not be able to reach is usually the finding — prefer this over disabling security controls, changing quotas/limits, or mutating another user.
   2. If a reversible state-changing write is the only convincing proof, capture the current value, make the change, capture evidence (response/screenshot), then immediately restore the original value — and prefer your own account or a throwaway account you registered for this test over a shared or provided account. Do NOT rely on end-of-run cleanup alone; a crash mid-run can strip it before it runs.
@@ -495,7 +503,7 @@ function destructiveSection(allow) {
 function rateLimitTestingSection(allow) {
   return allow ? SECTION_RATE_LIMITING_TESTING_ALLOWED : SECTION_RATE_LIMITING_TESTING_BLOCKED;
 }
-function buildPentestSystemPrompt(session, role = "orchestrator", mode = "default") {
+function buildPentestSystemPrompt(session, role = "orchestrator", mode = "default", systemScope) {
   const destructive = destructiveSection(session.config?.allowDestructiveActions);
   const rateLimitTesting = rateLimitTestingSection(session.config?.allowRateLimitTesting);
   const guardrails = `${destructive}
@@ -503,10 +511,13 @@ function buildPentestSystemPrompt(session, role = "orchestrator", mode = "defaul
 ${rateLimitTesting}
 
 ${SECTION_SIDE_EFFECT_SAFETY}`;
+  const systemSection = systemScope && systemScope.memberHosts.length > 0 ? `
+
+${SECTION_SYSTEM_SCOPE(systemScope.memberHosts)}` : "";
   if (mode === "fast-strike") {
     const withGuardrails2 = `${PENTEST_SYSTEM_PROMPT_STRIKE}
 
-${guardrails}`;
+${guardrails}${systemSection}`;
     return session.config?.promptInjectionLibrarySource ? `${withGuardrails2}
 
 ${SECTION_PROMPT_INJECTION}` : withGuardrails2;
@@ -514,27 +525,34 @@ ${SECTION_PROMPT_INJECTION}` : withGuardrails2;
   if (role === "orchestrator") {
     return `${PENTEST_SYSTEM_PROMPT_ORCHESTRATOR}
 
-${guardrails}`;
+${guardrails}${systemSection}`;
   }
   const taskDriven = session.config?.taskDriven ?? false;
   const exfilMode = session.config?.exfilMode ?? false;
   const base = taskDriven ? exfilMode ? PENTEST_SYSTEM_PROMPT_TASK_DRIVEN_EXFIL : PENTEST_SYSTEM_PROMPT_TASK_DRIVEN : exfilMode ? PENTEST_SYSTEM_PROMPT_EXFIL : PENTEST_SYSTEM_PROMPT_BASE;
   const withGuardrails = `${base}
 
-${guardrails}`;
+${guardrails}${systemSection}`;
   return session.config?.promptInjectionLibrarySource ? `${withGuardrails}
 
 ${SECTION_PROMPT_INJECTION}` : withGuardrails;
 }
+var SECTION_SYSTEM_SCOPE = (memberHosts) => `System Scope (structured):
+- This engagement covers a multi-application System. Member hosts already present in session targets: ${memberHosts.join(", ")}.
+- Declared relationships in the application context prioritize investigation order; undeclared paths between members remain in scope when discovered.
+- For cross-service follow-ups, an orchestrator MAY set a worker \`target\` to a full URL on another member host listed above. Workers receive this same System Scope. Do not invent hosts outside that set.
+- Authentication state is origin-specific. Before dispatching an authenticated cross-service follow-up, the orchestrator must establish and verify a session on that member origin. The worker must verify access on its assigned origin and follow the Authentication rules below if access is denied.
+- When a confirmed finding spans multiple members, populate the \`attackPath\` argument of \`document_vulnerability\` with the ordered member-to-member hop chain. Do not leave the chain only in the narrative.`;
 var SECTION_ORCHESTRATOR_DELEGATION = `Sub-Agent Delegation Rules:
 - You DO NOT call document_vulnerability directly. Findings are documented by the workers you spawn.
 - You DO NOT execute deep exploitation attempts yourself. Your tools (execute_command, http_request, browser_*) are for INITIAL RECON only — fingerprinting, sanity-checking the target, observing baseline behavior.
 - Each spawn_pentest_agent call MUST cover exactly ONE objective from the assignment, plus optional supporting context. Do not batch multiple objectives into one spawn — the UI surfaces each spawn as its own timeline, and per-objective spawns give each worker a clean, focused context window.
-- Target URL propagation: the \`target\` you received already encodes the specific domain + endpoint path the caller wants tested (e.g. https://example.com/api/users/{id}). Forward that EXACT URL into every spawn_pentest_agent call's \`target\` field. Do NOT strip the path back to a bare domain, do NOT swap the path for some other endpoint, and do NOT invent new endpoints — workers do not perform endpoint discovery, they deeply test the path they are given. The only time a worker's \`target\` should differ from yours is when recon surfaced a closely-related sibling endpoint on the same host that belongs to a follow-up objective; even then, send the full URL with the new path, not a bare host.
-- After all per-objective workers complete, spawn ONE final "chain & explore" worker. Pass it: a brief summary of what earlier workers found (or didn't find), plus any anomalous behaviors observed during recon. Its job is to chain confirmed findings into higher-impact attacks AND probe for additional vulnerabilities that fall outside the original objective list. Send it the same endpoint URL unless an earlier worker confirmed a vulnerability on a sibling endpoint that the chain depends on — in which case pass that sibling's full URL.
+- Target URL propagation: use the full assigned URL by default and never strip it to a bare domain. A worker may receive a recon-supported sibling endpoint that belongs to its follow-up objective. Change hosts only for a cross-service follow-up when the structured System Scope explicitly lists that member host. Always send a full URL, and never invent a host or endpoint outside the authorized session scope.
+- After all per-objective workers complete, spawn ONE final "chain & explore" worker. Pass it: a brief summary of what earlier workers found (or didn't find), plus any anomalous behaviors observed during recon. Its job is to chain confirmed findings into higher-impact attacks AND probe for additional vulnerabilities that fall outside the original objective list. Send it the same endpoint URL unless an earlier worker confirmed a vulnerability on a related sibling endpoint — including an explicitly listed System Scope member — that the chain depends on; then pass that endpoint's full URL.
 - Do not call spawn_pentest_agent before stating your plan in plain text. The plan must be visible to the user as an assistant message, not just inferred from tool calls.
 - Cloned browser session — every worker you spawn gets its OWN isolated Chromium, seeded at spawn time with a snapshot of your current cookies and per-origin localStorage. Practical implications:
-  - If authentication is required, log in ONCE in YOUR browser during recon. Every worker you spawn after that will start already authenticated — do NOT instruct workers to re-authenticate. Workers that authenticate themselves only authenticate their own cloned browser, so re-auth wastes turns.
+  - If authentication is required, authenticate in YOUR browser during recon. Workers assigned to an origin you authenticated will start with that state, so do NOT instruct them to re-authenticate up front.
+  - Authentication does not automatically carry to another origin. Before spawning a cross-service worker that needs authenticated access, establish and verify a session on its target origin. Tell the worker which origin was verified; if access is denied, it must follow the Authentication rules below rather than treating one 401/403 as a blocking authentication failure.
   - Worker browser actions are LOCAL to the worker's clone. A worker's navigations, form fills, \`browser_evaluate\` mutations, and \`localStorage\`/\`sessionStorage\` writes are NOT visible to you or to sibling workers. So workers can fire payloads, trigger alerts, or clobber DOM state without breaking each other or you.
   - Conversely, if you want state to be visible to the next worker, set it up in YOUR browser before spawning. Each worker sees the snapshot of your browser AT THE MOMENT YOU CALL spawn_pentest_agent — later mutations in your browser propagate to subsequent spawns but not to in-flight workers.
   - Worker sessions are torn down when the worker finishes, so any cookies the worker acquired during testing (post-auth flows, OAuth callbacks, etc.) are discarded. If a worker discovers a useful login flow, summarize the credentials in your final response or repeat the flow in YOUR browser before the next spawn.`;
@@ -550,7 +568,7 @@ Your methodology:
 3. RECON & AUTHENTICATE — Perform LIGHT initial reconnaissance to confirm the target is reachable and understand baseline behavior. Use http_request for a handful of probes, browser_navigate + browser_snapshot to see the surface, and execute_command sparingly. Do NOT begin exploitation here — that is the workers' job. Note any anomalies (unusual error responses, exposed headers, framework fingerprints, surprising endpoint behavior) for the final exploratory worker.
    - If authentication is required (an "Existing Authentication Session" section is absent and the target / objectives need a logged-in session), you MUST authenticate NOW, in YOUR browser, BEFORE any fan-out. Follow the "Available Credentials" instructions exactly — use the method each credential's Context describes (e.g. a token/API exchange via execute_command or http_request) rather than defaulting to a browser login; only drive the browser login flow (browser_navigate + browser_fill with credentialId/credentialField) when the Context does not specify how.
    - VERIFY the session before fanning out: request a protected resource and confirm it does NOT return 401/403. Use browser_get_cookies to capture the session cookies for reuse in raw http_request / curl calls.
-   - Authenticating HERE (not in the workers) is critical: each worker you spawn inherits a snapshot of YOUR browser's authenticated cookies + localStorage at spawn time, so ONE successful login up front propagates to every worker. Do NOT instruct workers to re-authenticate.
+   - Authenticating HERE (not in the workers) is critical: each worker you spawn inherits YOUR browser's cookies + localStorage for origins where you established a session. Before an authenticated cross-service spawn, establish and verify the session on that member origin too. Do NOT instruct a worker to re-authenticate up front for an origin you already verified; if access is denied, it must follow the Authentication rules below.
    - If you cannot authenticate and the objectives require it, call report_error with reason "authentication_failed" and a specific message BEFORE spawning any workers — do not fan out unauthenticated workers that will all fail, and do not report non-findings.
 4. FAN OUT — For EACH objective, call spawn_pentest_agent EXACTLY ONCE. Each spawn dispatches a focused worker that will perform the full PLAN → VERIFY → PREPARE → TEST → EXPLOIT → DOCUMENT loop on its objective. Workers write findings to the shared findings registry — you do NOT need to forward findings between them.
 5. CHAIN & EXPLORE — After all per-objective workers complete, call spawn_pentest_agent ONE FINAL TIME with a synthesized objective that:
@@ -588,7 +606,7 @@ function buildPentestPrompt(target, objectives, session, findingsRegistry, conte
         const parts = [
           `
 ## Existing Authentication Session`,
-          `An authenticated session already exists — **do NOT re-authenticate**. Include these credentials in every request.
+          `An authenticated session already exists. Use these credentials on the origin they authorize and do not re-authenticate up front there. On another structured System member origin, verify protected access first; if access is denied, follow the system Authentication rules.
 `
         ];
         if (authData.cookies) {
@@ -690,18 +708,19 @@ Do NOT discover or enumerate other endpoints or services. Focus exclusively on t
 1. Call list_memories to review any prior knowledge relevant to this target or engagement.
 2. State the objectives and outline your orchestration plan in plain text BEFORE any tool calls — one bullet per objective, briefly naming the attack class each worker should focus on.
 3. Perform LIGHT initial recon (a handful of http_request probes, browser_navigate + browser_snapshot to see the surface). Do NOT begin exploitation here — that is the workers' job. Note any anomalies you observe for the final exploratory worker.
-   - AUTHENTICATE FIRST if the target/objectives need a logged-in session and no "Existing Authentication Session" is provided: log in ONCE in YOUR browser during this recon step, following the "Available Credentials" instructions exactly (prefer the credential Context's method; use credentialId/credentialField so secrets resolve securely). Verify the session with a protected request (expect NOT 401/403) and capture cookies via browser_get_cookies. Every worker inherits your authenticated browser snapshot, so do this BEFORE fan-out and do NOT have workers re-authenticate. If you cannot authenticate and the objectives require it, call report_error with reason "authentication_failed" instead of fanning out.
+   - AUTHENTICATE FIRST if the target/objectives need a logged-in session and no "Existing Authentication Session" is provided: authenticate in YOUR browser during this recon step, following the "Available Credentials" instructions exactly (prefer the credential Context's method; use credentialId/credentialField so secrets resolve securely). Verify the session with a protected request (expect NOT 401/403) and capture cookies via browser_get_cookies. Workers inherit auth only for origins where you established it. Before an authenticated cross-service spawn, establish and verify a session on that member origin too. Do not have workers re-authenticate up front on a verified origin; if access is denied, the worker must follow the system Authentication rules. If you cannot authenticate and the objectives require it, call report_error with reason "authentication_failed" instead of fanning out.
 4. Call spawn_pentest_agent EXACTLY ONCE PER OBJECTIVE. For every spawn:
-   - Set \`target\` to the FULL URL from the assignment above (domain + endpoint path) — pass it through verbatim. Do not strip the path or rewrite the host. Workers do not perform endpoint discovery; they deeply test the path you hand them.
+   - Use the FULL URL from the assignment above (domain + endpoint path) by default; never strip it to a bare domain. A recon-supported sibling endpoint may be used when it belongs to the objective. Rewrite the host only for a cross-service follow-up when the structured System Scope explicitly lists that member host. Always pass a full URL and never invent a host or endpoint outside the authorized session scope.
+   - Authentication state is origin-specific. If an authenticated cross-service follow-up changes origins, establish and verify auth on that member origin before spawning. Tell the worker which origin was verified and whether authenticated access is still required.
    - Pass the matching objective in the \`objectives\` array (a single-element array).
    - Use the \`context\` field to forward any recon insights specific to that objective. If your earlier browser actions left state the worker should know about (already logged in as X, certain modal already dismissed), call that out in \`context\` — each worker is seeded with a snapshot of YOUR browser's cookies and localStorage at the moment of the spawn call.
-5. After all per-objective workers complete, call spawn_pentest_agent ONE FINAL TIME with a synthesized "chain & explore" objective: summarize what earlier workers confirmed/ruled out, call out unaddressed anomalies, and direct the worker to chain confirmed findings AND probe for additional vulnerabilities outside the original objective list. Send it the same endpoint URL as your assignment unless an earlier worker's confirmed finding on a sibling endpoint is what makes the chain possible.
+5. After all per-objective workers complete, call spawn_pentest_agent ONE FINAL TIME with a synthesized "chain & explore" objective: summarize what earlier workers confirmed/ruled out, call out unaddressed anomalies, and direct the worker to chain confirmed findings AND probe for additional vulnerabilities outside the original objective list. Send it the same endpoint URL as your assignment unless an earlier worker's confirmed finding on a related sibling endpoint — including an explicitly listed System Scope member — is what makes the chain possible.
 6. Use add_memory to save reusable learnings from this engagement.
 7. Call the response tool with your final summary. Compile objectiveResults from worker reports, and populate newObjectives directly from the coverage you orchestrated (worker outcomes, confirmed/ruled-out results, unexplored recon anomalies, technology fingerprints) — a small focused set of objectives for the next run that are not already tested this run or completed in your context. Empty array only if the endpoint is genuinely exhausted.
 
 If your assignment lists ZERO open objectives (everything is already completed), skip steps 4-5, do light recon only, then finish — still populating newObjectives so the run is productive rather than re-testing completed objectives.
 
-Do NOT call document_vulnerability — that is the workers' job. Do NOT discover or enumerate other endpoints or services beyond the assigned target.`;
+Do NOT call document_vulnerability — that is the workers' job. Do NOT discover or enumerate other endpoints or services beyond the assigned target except for cross-service follow-ups explicitly authorized by the structured System Scope.`;
   const instructions = role === "orchestrator" ? orchestratorInstructions : taskDriven ? taskDrivenInstructions : exfilMode ? `## Goal
 Your target is a flag with the format FLAG{...}. Locate and extract it.
 
@@ -728,7 +747,8 @@ Your target is a flag with the format FLAG{...}. Locate and extract it.
 Do NOT discover or enumerate other endpoints or services. Focus exclusively on the target and objectives above.`;
   const credentialSection = credentialContext ? `
 ## Available Credentials
-The operator provided the following credentials and authentication instructions for this engagement. Authenticate by following the instructions in each credential's Context exactly — use the method it describes (for example, a token/API exchange via execute_command or http_request) rather than defaulting to a browser login. Treat the Context as the source of truth for how to authenticate, and how to re-authenticate if a provided session expires. When a tool needs a secret value and supports it (e.g. browser_fill), reference it by credentialId + credentialField so the secret resolves securely at execution time instead of hardcoding it. If you cannot authenticate with these, call report_error with reason "authentication_failed" and a specific message rather than reporting a non-finding.
+The operator provided the following credentials and authentication instructions for this engagement. Authenticate by following the instructions in each credential's Context exactly — use the method it describes (for example, a token/API exchange via execute_command or http_request) rather than defaulting to a browser login. Treat the Context as the source of truth for how to authenticate, and how to re-authenticate if a provided session expires. When a tool needs a secret value and supports it (e.g. browser_fill), reference it by credentialId + credentialField so the secret resolves securely at execution time instead of hardcoding it. If required authentication cannot be established and blocks the assigned objective or all further testing, call report_error with reason "authentication_failed" and a specific message; otherwise continue reachable testing and report the limitation in your final response.
+When a credential has additional field phoneNumber, phone is the login identifier (not MFA-after-password). Fill credentialField="phoneNumber", click send-code, sleep with execute_command, then sms_list_messages with sinceMs from that click (claim=true once a message is present). If the list stays empty, stop and report — do not hang. Do not report phone_verification as a barrier. TOTP-via-environment-variable for authenticator MFA is unchanged.
 
 ${credentialContext}
 ` : "";
@@ -806,6 +826,7 @@ var SHARED_PENTEST_TOOLS = [
   "email_search_messages",
   "email_get_message",
   "send_email",
+  "sms_list_messages",
   "list_memories",
   "get_memory",
   "add_memory",

package/build/{cli-xshasbwe.js → cli-4mgj070h.js}

@@ -1,9 +1,9 @@
 import {
   OffensiveSecurityAgent
-} from "./cli-repbyhkk.js";
+} from "./cli-4vwnsyep.js";
 import {
   detectOSAndEnhancePrompt
-} from "./cli-tznv8pf1.js";
+} from "./cli-gbch9xmy.js";
 import {
   createLogger,
   hasToolCall,
@@ -11,7 +11,7 @@ import {
   init_lazyLogger,
   init_structured,
   scopedLogger
-} from "./cli-tkc598ey.js";
+} from "./cli-f47dgye3.js";
 
 // src/core/agents/specialized/authenticationAgent/agent.ts
 init_dist();
@@ -141,6 +141,23 @@ every 30 seconds, so run this immediately before filling the field. If the code
 retry once (you may have crossed a period boundary). Only report an MFA barrier if no seed is available
 or two fresh codes are both rejected.
 
+# SMS passwordless (phone as login)
+
+If a credential has a \`phoneNumber\` additional field, the phone number IS the login identifier — not MFA
+after a password. Do **not** report \`phone_verification\` as a barrier for this flow.
+
+1. \`browser_fill\` with \`credentialId\` and \`credentialField="phoneNumber"\` (never type the number).
+2. Click the target's send-code / text-me control. Note \`Date.now()\` at that click as \`sinceMs\`.
+3. \`execute_command\` \`sleep 5\`, then call \`sms_list_messages\` with that \`credentialId\` and \`sinceMs\`.
+   If the list is empty, sleep and list again a few times. If it stays empty or returns an error, stop
+   and report what you observed — do not hang in a wait loop. Set \`claim=true\` once a message is present
+   so other runs cannot reuse the OTP.
+4. \`browser_fill\` the OTP from the claimed/listed result (\`code\`, or parse \`body\` if \`code\` is null).
+5. Continue the login and call \`complete_authentication\`.
+
+TOTP-via-environment-variable above is unchanged and still applies when the login asks for an authenticator
+app code.
+
 # Error Recovery
 
 If authentication fails, try these mechanical fixes (they are login mechanics, not credential changes):
@@ -243,6 +260,7 @@ class AuthenticationAgent extends OffensiveSecurityAgent {
         "email_search_messages",
         "email_get_message",
         "send_email",
+        "sms_list_messages",
         "web_search",
         "get_page"
       ],
@@ -328,6 +346,14 @@ function buildAuthPrompt(target, authHints, credentialManager, context, envVarNa
     parts.push("");
   }
   if (credBlock) {
+    const hasSmsPasswordless = credentialManager?.listReferences().some((ref) => ref.additionalFieldKeys?.includes("phoneNumber"));
+    const smsInstructions = hasSmsPasswordless ? `
+If a credential has a phoneNumber additional field (Mobile OTP / sms-passwordless), phone is the login
+identifier — not MFA-after-password. browser_fill credentialField="phoneNumber", click send-code, then
+execute_command \`sleep 5\` and call sms_list_messages with sinceMs = Date.now() at that click (claim=true
+once a message is present). If the list is empty, sleep and list again; if it stays empty, fail with what
+you observed — do not hang waiting. Then browser_fill the OTP. Do NOT report phone_verification as a
+barrier for this flow. TOTP-via-env for authenticator MFA is unchanged.` : "";
     parts.push(`INSTRUCTIONS:
 You have credentials available via credential IDs — authenticate immediately.
 1. For API/form logins, use execute_command (curl) to submit credentials and capture the Set-Cookie / token response
@@ -335,7 +361,7 @@ You have credentials available via credential IDs — authenticate immediately.
    pass credentialId + credentialField (e.g. credentialField="password") instead of the raw value —
    the secret is resolved securely at execution time. NEVER type a password directly.
 3. Call complete_authentication with exported cookies/headers to persist credentials and end the run
-
+${smsInstructions}
 The credentials above were provided to you and have already been verified — they are SHARED across runs, so
 do not modify them or their account settings. NEVER change the password, complete a password reset /
 forced-password-change / account-recovery flow, or modify MFA/2FA settings (enrolling, disabling, or