{"version":"2.1.280","anchor":"permission-mode-changes-from-a-dialog-answer-are-now-reporte","canonical_anchor":"permission-mode-changes-from-a-dialog-answer-are-now-reporte","heading":"Permission-mode changes now track whether you or the remote worker made them","tier":"internal","area":"Permissions","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/permission-mode-changes-from-a-dialog-answer-are-now-reporte","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### Permission-mode changes now track whether you or the remote worker made them\n\nClaude Code now tags permission-mode changes with their origin so the UI doesn't confuse your own change for a remote one\n\n**What**\n\nWhen the permission mode (such as switching to 'default' or 'acceptEdits') changes, Claude Code now keeps track of whether that change came from you answering a permission prompt or from elsewhere, such as a remote worker.\n\n- When a permission-request response sets the session-scoped mode to `default` or `acceptEdits`, the UI now calls a new `noteOwnPermissionModeAnswer` callback, alongside a parallel `noteOwnPermissionModePush`, so the outer session layer can attribute the change to answering a permission dialog.\n\n- In Remote Control's transport layer, the permission-mode change handler now takes an `origin` argument distinguishing a mode set by the person from one set by the worker, and the same `noteOwnPermissionModePush`\/`noteOwnPermissionModeAnswer` methods track locally-initiated mode changes through a `modeWire` structure.\n\n**Why**\n\nThis prevents the interface from mistakenly echoing back a permission-mode change as if it came from somewhere else when it was really something you just did yourself, particularly during remote\/worker sessions.\n\n- Area: Permissions\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}