{"version":"2.1.280","anchor":"attach-vs-create-sessions-get-different-opening-initialize","canonical_anchor":"attach-vs-create-sessions-get-different-opening-initialize","heading":"Attach vs. create sessions get different \"opening initialize honours\" sets","tier":"internal","area":"Session Management","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/attach-vs-create-sessions-get-different-opening-initialize","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### Attach vs. create sessions get different \"opening initialize honours\" sets\n\nAttaching to an existing headless session now honours a caller-supplied list instead of always getting an empty one\n\n**Unclear.** The finding does not say what settings are in the `t1n` list or what values callers pass for `attachHonours`, so the practical effect on attach behavior isn't clear.\n\n**What**\n\nClaude Code can open a headless session (one run without the interactive UI) either by creating a new session or by attaching to one already running. Internally, opening a session applies a set of \"opening initialize honours\", settings that get applied when the session starts. Previously, attaching to a session always passed an empty set of these, so none applied. Now the code that opens a session takes an `attachHonours` parameter: a brand-new session still always uses a fixed set, but attaching now uses whatever `attachHonours` the caller supplies.\n\n**Why**\n\nThis lets attaching to an existing session carry over initialize settings that were previously always dropped, so behavior on attach can now depend on what the caller passes rather than always starting from nothing.\n\n- Area: Session Management\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}