@@ -0,0 +1 @@
+**A CodeLLDB attach's initial stop is reported as a pause, not an exception** — on Windows, attaching to a process by PID (C/C++ and COBOL) reported the target's post-attach stop as `lastStop.reason: "exception"` / `stopReason: "exception"` with `Exception 0x80000003 encountered at address …`: that is the `DebugBreakProcess` break-in Windows injects to stop the target for the attach, on a helper thread, and nothing in the program threw. CodeLLDB stops the target itself when the attach did not opt out of `stopOnEntry`, so the session layer never armed the pause intent the shared normalizer keyed on; the first stop of such an attach is now `pause`, with the adapter's own reason kept as `rawReason: "exception"` and its description beside it. The stop-reason context's `stopOnEntry` now reads an attach the way the attach controller and the adapters do — stop unless told not to — so a real `__debugbreak()` met first by an attach that passed `stopOnEntry: false` stays an exception (#817)
@@ -146,7 +146,7 @@ attach_to_process sessionId=... processId=<pid> adapterConfig={"manifestDirs": [
 - On Windows the attach stop is reported on the break thread the OS injects (exception `0x80000003`), a pause may land on a runtime worker thread: when the reported thread has no COBOL frame, the shim reports the stop on the thread that is inside the COBOL program (the description names both), so `get_stack_trace` shows the program on first contact. Breakpoint, step, entry and runtime-error stops are always on the right thread and are left alone.
 - A batch job is usually paused inside libcob or a `C$SLEEP`/I/O call, a frame with no COBOL source: `get_scopes`, `get_local_variables` and `evaluate_expression` then serve the nearest COBOL program up the stack (the scope names say whose and how far up, `WORKING-STORAGE of PAYROLL (0000-MAIN, 3 frames up)`), so the data division is visible on first contact; `get_stack_trace` shows the COBOL frame's paragraph.
 - When the client that started the session goes away (the server or the proxy dies), the shim detaches: an attached process is never terminated the way a launched one is.
-- The target is held paused after attach (`stopOnEntry` is a top-level `attach_to_process` parameter and defaults to `true`; pass `false` to resume immediately).
+- The target is held paused after attach (`stopOnEntry` is a top-level `attach_to_process` parameter and defaults to `true`; pass `false` to resume immediately). That initial stop is reported as `lastStop.reason: "pause"`; on Windows the adapter's own words stay beside it as `rawReason: "exception"` and the `0x80000003` description (issue #817; the mechanism is in the C/C++ guide's attach section).
 - Recognised `adapterConfig` keys: `processId`/`pid`, `program` (CodeLLDB's explicit-binary hint; a relative path is resolved against `cwd` before it reaches CodeLLDB), `cwd`, `waitFor`, `manifestDirs`, `engineScopes`, `sources`, `dialect`, `format`, `copybookDirs`, `cobcFlags`, `runtimeChecks`, `forceRebuild`, `initCommands`, `preRunCommands`, `postRunCommands`, `exitCommands`, `targetCreateCommands`, `processCreateCommands`, `expressions`, `sourceMap`, `sourceLanguages`, `relativePathBase`, `breakpointMode`. The manifest keys (`sources` … `forceRebuild`, `manifestDirs`, `engineScopes`, `cwd`) are consumed by the adapter and never appear in the attach request, and are not reported as ignored. Unlisted keys are still forwarded, with a warning naming them.
 - The regeneration runs before CodeLLDB is spawned, under the attach's `timeout` (default 30 s) less a margin; a cached translate (unchanged sources and options) is instant, a first one is a cobc run.
 - `detach_from_process` leaves the target running. On Windows a stopped target is resumed (DAP `continue`) before the detaching `disconnect` — on detach, on `close_debug_session` and on shutdown — and the detach result reports `data.resumedBeforeDetach: true`: the engine is CodeLLDB, whose Windows detach otherwise kills a target whose last resume was a step (issue #763; the mechanism is in the C/C++ guide's attach section).
 
@@ -49,7 +49,7 @@ Compile with **`-gdwarf-4 -O0`**: full debug info, no optimization (optimized co
 attach_to_process sessionId=... processId=<pid>
 ```
 
-- The target is held paused after attach (`stopOnEntry` defaults to `true` for attach in every language, not just C/C++; pass `false` to resume immediately).
+- The target is held paused after attach (`stopOnEntry` defaults to `true` for attach in every language, not just C/C++; pass `false` to resume immediately). That initial stop is reported as `lastStop.reason: "pause"` (`stopReason: "pause"` in `get_stack_trace`). On Windows it is the `DebugBreakProcess` break-in Windows injects to stop the target, which CodeLLDB reports as an `0x80000003` exception on a helper thread — the adapter's own words stay beside the pause as `rawReason: "exception"` and `description: "Exception 0x80000003 encountered at address …"`, and the anchored thread is the program's (issue #817). A `stopOnEntry: false` attach has no initial stop, so a break-in met first there (a real `__debugbreak()`) is reported as the exception it is.
 - `detach_from_process` leaves the target running. On Windows a stopped target is resumed (DAP `continue`) before the `disconnect` — on detach, on `close_debug_session` and on shutdown — and the detach result reports `data.resumedBeforeDetach: true`: CodeLLDB's Windows detach resumes each thread with the resume state of its last stop, and after a `step_over`/`step_into` that state is still "stepping", so the target would single-step with no debugger attached and exit with `STATUS_SINGLE_STEP` (`0x80000004`) (issue #763). A refused continue leaves `resumedBeforeDetach: false` and a `data.warning`.
 - **Linux**: `kernel.yama.ptrace_scope=1` (the default on many distros) only allows attaching to child processes. For arbitrary processes: `sudo sysctl kernel.yama.ptrace_scope=0` (temporary) or run the server with `CAP_SYS_PTRACE`.
 - **Windows**: attach requires same-or-higher privilege than the target.
 
@@ -1235,6 +1235,7 @@ When the requested pause has not landed by the time the tool answers (an idle No
 
 **Notes:**
 - `state` is `"paused"` only once a stopped event has actually been observed; otherwise the attach reports `"running"`. When a requested post-attach pause is accepted but its stopped event has not arrived within the bounded wait, the response is successful with `state: "running"` and `pending: true` (at the top level and in `data`) and the `message` names the pending pause; the late stopped event is the only transition to `paused`, and every paused session has a `lastStop`.
+- The initial stop of an attach is reported as `lastStop.reason: "pause"` (`stopReason: "pause"` in `get_stack_trace`) by every adapter, whether the debugger paused the target on request or, as CodeLLDB does, stopped it itself. On Windows, CodeLLDB reports that stop as the `DebugBreakProcess` break-in — an `0x80000003` exception on a helper thread — so the adapter's own words stay beside the pause as `lastStop.rawReason: "exception"` and `description: "Exception 0x80000003 encountered at address …"` (issue #817). Only the first stop of an attach that did not pass `stopOnEntry: false` is read this way: a break-in met later, or first by an attach that opted out of the initial stop, is a real `__debugbreak()` and keeps `reason: "exception"`.
 - When `processId` was used, the message reads `Attached to process PID <pid>` instead.
 - The response `warning` reports two distinct `adapterConfig` key outcomes (issues #450/#466): keys the adapter's attach transform genuinely drops (e.g. Python's ptvsd-era `localRoot`/`remoteRoot` — use `pathMappings`) are named as **ignored**, while keys mcp-debugger doesn't recognize are **forwarded to the adapter as-is** and named with an edit-distance suggestion for near-misses (`pathMapping (did you mean pathMappings?)`) — "ignored" means dropped, "forwarded as-is" means the adapter still sees them. The same field also carries the launch-style warning for function breakpoints still unverified at attach (issue #308).
 - js-debug attach honors `adapterConfig` too: `localRoot`/`remoteRoot`/`sourceMaps`/`skipFiles`/`continueOnAttach` and other js-debug attach options reach the debugger (issue #466). Two keys are defaulted when absent (issue #655): `resolveSourceMapLocations: ["**", "!**/node_modules/**"]` (js-debug's own attach default collapses to "resolve everywhere", which applied every dependency's `.js.map` and produced phantom `../src/*.ts` frames) and `cwd` (the server's working directory, or the workspace root in container mode — js-debug needs a base path before it resolves any source map's relative `sources`, even ones next to the generated file). Pass your own value, including `resolveSourceMapLocations: null`, to override. `skipFiles` is deliberately left at js-debug's default: blackboxing `node_modules` would turn a `pause_execution` that lands in framework code on an idle server into the endless step-chase of issue #513 — `get_stack_trace` hides those frames instead.
 
@@ -94,7 +94,12 @@ export interface StopReasonContext {
   sessionMode?: 'launch' | 'attach';
   /** True for the first stop the session has seen since its launch/attach. */
   firstStop?: boolean;
-  /** The effective stopOnEntry of the launch, when known. */
+  /**
+   * Whether the session asked for an initial stop, read per mode: a launch
+   * stops on entry only when the caller asked (`stopOnEntry === true`); an
+   * attach stops unless the caller opted out (`stopOnEntry !== false`, the
+   * adapters' own default — issue #817).
+   */
   stopOnEntry?: boolean;
 }
 
 
@@ -31,6 +31,16 @@ export const LLDB_LOCAL_SCOPE_NAMES = ['Local', 'Locals'] as const;
  *    any platform-specific exception detail, so its generation-scoped
  *    intent is authoritative; public pauses retain the narrower Windows
  *    detail checks so coincident real exceptions are not mislabeled.
+ *    An attach's own initial stop is the same break-in with no intent to
+ *    lean on (issue #817): CodeLLDB stops the target itself when the attach
+ *    did not opt out of stopOnEntry, so the session layer never arms a pause,
+ *    and the stopped event (measured: `{allThreadsStopped, description:
+ *    "Exception 0x80000003 encountered at address 0x…", reason: "exception",
+ *    threadId}`) even precedes the attach response. That first stop of an
+ *    attach that asked to stop is 'pause' too — gated on the break-in code,
+ *    so a real __debugbreak() met first by an attach that opted out stays an
+ *    exception. (Measured on Windows; the POSIX shape of this stop is not
+ *    pinned yet — a SIGSTOP would fall under the first rule.)
  *
  * 2. An exception-filter hit (rust_panic, cpp_throw) is reported as reason
  *    'breakpoint' because CodeLLDB implements filters as internal
@@ -82,6 +92,20 @@ export function normalizeLldbStopReason(
   if (context.pauseSource === 'attach') {
     return 'pause';
   }
+  // The attach's own initial stop (issue #817): first stop of an attach that
+  // did not opt out of stopOnEntry, with no pause in flight, reported through
+  // the Windows break-in code. (On POSIX a ptrace attach stops the target
+  // with SIGSTOP, which the rule above would cover; that shape has not been
+  // measured for this stop — the cpp attach e2e logs it off Windows.)
+  if (
+    context.sessionMode === 'attach' &&
+    context.firstStop === true &&
+    context.stopOnEntry === true &&
+    !context.pausePending &&
+    /0x80000003/i.test(detail)
+  ) {
+    return 'pause';
+  }
   // Windows delivers a user-initiated pause via DebugBreakProcess: the
   // injected break-in thread raises EXCEPTION_BREAKPOINT (0x80000003),
   // which CodeLLDB reports as an exception stop (issue #275; captured
 
@@ -72,6 +72,49 @@ describe('CppAdapterPolicy', () => {
       expect(normalize('exception', body, baseContext)).toBeUndefined();
       expect(normalize('exception', body, { ...baseContext, pausePending: true })).toBe('pause');
     });
+
+    // An attach's own initial stop (issue #817): CodeLLDB stops the target
+    // itself, so no pause intent exists to arm; on Windows the
+    // DebugBreakProcess break-in is reported as 0x80000003 on a helper thread
+    // (measured body: {allThreadsStopped, description, reason, threadId}).
+    describe("the attach's initial stop (issue #817)", () => {
+      const breakIn = {
+        reason: 'exception',
+        description: 'Exception 0x80000003 encountered at address 0x7ff958103ab0'
+      };
+      const attachFirst: StopReasonContext = {
+        ...baseContext,
+        sessionMode: 'attach',
+        firstStop: true,
+        stopOnEntry: true
+      };
+
+      it("maps the break-in of a default attach to 'pause'", () => {
+        expect(normalize('exception', breakIn, attachFirst)).toBe('pause');
+      });
+
+      it('keeps a break-in when the attach opted out of the initial stop (a real __debugbreak came first)', () => {
+        expect(normalize('exception', breakIn, { ...attachFirst, stopOnEntry: false })).toBeUndefined();
+      });
+
+      it('keeps a break-in on a later stop of the attach session', () => {
+        expect(normalize('exception', breakIn, { ...attachFirst, firstStop: false })).toBeUndefined();
+      });
+
+      it("keeps a launch's first-stop break-in (a launch entry stop arrives as 'entry', not as an exception)", () => {
+        expect(normalize('exception', breakIn, { ...attachFirst, sessionMode: 'launch' })).toBeUndefined();
+      });
+
+      it('keeps a first-stop exception whose detail is not the break-in code', () => {
+        expect(
+          normalize(
+            'exception',
+            { reason: 'exception', description: 'Exception 0xc0000005 encountered at address 0x1' },
+            attachFirst
+          )
+        ).toBeUndefined();
+      });
+    });
   });
 
   describe('extractLocalVariables (shared LLDB scope handling)', () => {
 
@@ -152,6 +152,18 @@ describe('RustAdapterPolicy', () => {
       ).toBeUndefined();
     });
 
+    // The shared normalizer also owns an attach's own initial stop (issue
+    // #817): CodeLLDB stops the target itself, so no pause intent is armed,
+    // and Windows reports the DebugBreakProcess break-in as 0x80000003.
+    it("maps the break-in of an attach's own initial stop to pause (issue #817)", () => {
+      const breakIn = { reason: 'exception', description: 'Exception 0x80000003 encountered at address 0x7ff958103ab0' };
+      const attachFirst: Partial<StopReasonContext> = { sessionMode: 'attach', firstStop: true, stopOnEntry: true };
+      expect(normalize('exception', breakIn, ctx(attachFirst))).toBe('pause');
+      expect(normalize('exception', breakIn, ctx({ ...attachFirst, stopOnEntry: false }))).toBeUndefined();
+      expect(normalize('exception', breakIn, ctx({ ...attachFirst, firstStop: false }))).toBeUndefined();
+      expect(normalize('exception', breakIn, ctx({ ...attachFirst, sessionMode: 'launch' }))).toBeUndefined();
+    });
+
     it('never touches step or pause reasons', () => {
       expect(normalize('step', { reason: 'step' }, ctx())).toBeUndefined();
       expect(normalize('pause', { reason: 'pause' }, ctx({ pausePending: true }))).toBeUndefined();
 
@@ -115,7 +115,9 @@ export class AttachController {
     const { verifyTimeout, breakOnExceptions, adapterConfig, ...adapterAttachConfig } = attachConfig;
     if (adapterConfig && adapterConfig.stopOnEntry !== undefined) {
       this.ctx.logger.warn(
-        '[SessionManager] adapterConfig.stopOnEntry reaches the adapter but does not affect post-attach pause verification; prefer the top-level stopOnEntry parameter'
+        '[SessionManager] adapterConfig.stopOnEntry reaches the adapter (and is what the stop-reason reading of the ' +
+          'attach\'s initial stop follows) but does not affect post-attach pause verification; prefer the top-level ' +
+          'stopOnEntry parameter'
       );
     }
     // Same rules as every per-request 'timeout' override: positive finite
@@ -186,9 +188,16 @@ export class AttachController {
       // The actual attach logic will be handled by the adapter via dapLaunchArgs
       const placeholderPath = 'attach://remote';
 
-      // Pass attach config through dapLaunchArgs with special request type
+      // Pass attach config through dapLaunchArgs with special request type.
+      // stopOnEntry as the adapter will receive it: adapterConfig wins the
+      // merge the proxy launcher applies (issue #336), and the core's mode
+      // facts — the stop-reason reading of the attach's initial stop (issue
+      // #817) and the RUNNING projection — must follow the value that reached
+      // the debugger, not a top-level default the adapter never saw. The
+      // verification gate below keeps reading the top-level parameter.
       const attachLaunchArgs = {
         ...adapterAttachConfig,
+        ...(typeof adapterConfig?.stopOnEntry === 'boolean' ? { stopOnEntry: adapterConfig.stopOnEntry } : {}),
         request: 'attach',
         __attachMode: true  // Internal flag to signal attach mode
       };
 
@@ -587,6 +587,16 @@ export abstract class SessionManagerCore extends EventEmitter {
       const isAttachSession =
         launchArgsRecord.request === 'attach' ||
         launchArgsRecord.__attachMode === true;
+      // Whether the session asked for an initial stop. The two modes default
+      // differently: a launch stops on entry only when asked (`=== true`), an
+      // attach stops unless told not to (`!== false`) — the reading the attach
+      // controller and the adapters (CodeLLDB's `stopOnEntry ?? true`) apply.
+      // A default attach reaches here as `stopOnEntry: undefined`: the launch
+      // default (false) is spread first and the caller's undefined key over it
+      // (issue #817).
+      const stopOnEntry = isAttachSession
+        ? effectiveLaunchArgs.stopOnEntry !== false
+        : effectiveLaunchArgs.stopOnEntry === true;
       try {
         const policy = this.sessionStore.selectPolicy(session.language);
         // Collect the adapter-assigned ids of all user breakpoints so the
@@ -619,15 +629,16 @@ export abstract class SessionManagerCore extends EventEmitter {
           lineComplete && fnComplete ? new Set([...lineIds, ...fnIds]) : undefined;
         pauseIntent = getCurrentPauseIntent(session);
         // Mode facts for policies whose adapter reports a launch's entry stop
-        // under a generic reason (rdbg's `pause`, issue #798): a launch or an
-        // attach, the first stop or a later one, and whether the launch asked
-        // for an entry stop at all.
+        // under a generic reason (rdbg's `pause`, issue #798) or an attach's
+        // own initial stop as an exception (CodeLLDB's Windows break-in, issue
+        // #817): a launch or an attach, the first stop or a later one, and
+        // whether the session asked for an initial stop at all.
         const normalized = policy.normalizeStopReason?.(rawReason, body, {
           pausePending: pauseIntent !== undefined,
           ...(pauseIntent ? { pauseSource: pauseIntent.source } : {}),
           sessionMode: isAttachSession ? 'attach' : 'launch',
           firstStop: isFirstStop,
-          stopOnEntry: effectiveLaunchArgs.stopOnEntry === true,
+          stopOnEntry,
           userBreakpointIds,
           functionBreakpointIds: fnComplete ? fnIds : undefined,
           lineBreakpointCount: session.breakpoints.size,
@@ -676,7 +687,7 @@ export abstract class SessionManagerCore extends EventEmitter {
       const answersUserPause = pauseIntent?.source === 'user';
       const shouldAutoContinue =
         !isAttachSession &&
-        !effectiveLaunchArgs.stopOnEntry &&
+        !stopOnEntry &&
         !answersUserPause &&
         (reason === 'entry' ||
           (firstStopMayBeNonEntry && isFirstStop && !userBreakReasons.has(reason)));
Original file line number	Diff line number	Diff line change
`@@ -0,0 +1 @@`
	`1`	+A CodeLLDB attach's initial stop is reported as a pause, not an exception — on Windows, attaching to a process by PID (C/C++ and COBOL) reported the target's post-attach stop as `lastStop.reason: "exception"` / `stopReason: "exception"` with `Exception 0x80000003 encountered at address …`: that is the `DebugBreakProcess` break-in Windows injects to stop the target for the attach, on a helper thread, and nothing in the program threw. CodeLLDB stops the target itself when the attach did not opt out of `stopOnEntry`, so the session layer never armed the pause intent the shared normalizer keyed on; the first stop of such an attach is now `pause`, with the adapter's own reason kept as `rawReason: "exception"` and its description beside it. The stop-reason context's `stopOnEntry` now reads an attach the way the attach controller and the adapters do — stop unless told not to — so a real `__debugbreak()` met first by an attach that passed `stopOnEntry: false` stays an exception (#817)