Dyad v1.6 upgraded Electron from v40 to Electron v43 which introduced/exposed two separate regressions:
-
GitHub device flow fails at /login/device/code
-
Dyad uses node-fetch@2.7.0.
-
GitHub returns a valid 200 response with content-encoding: gzip and transfer-encoding: chunked.
-
In Electron 43, node-fetch@2 misfires its chunked-response “Premature close” heuristic and errors while reading the body.
-
Confirmed:
- Electron 40: same request succeeds.
- Electron 43: same request fails.
- Raw https.request in Electron 43 receives a complete response, so GitHub is not the problem.
-
Likely fix direction: avoid node-fetch@2 for this path, use native fetch/Undici or another HTTP client.
-
Existing safeStorage-encrypted secrets become unreadable
-
Electron 40 could touch macOS safeStorage before app.ready, which could initialize Keychain under the wrong identity: Chromium
Safe Storage.
-
Electron 43 changed safeStorage behavior and no longer uses that old pre-ready initialization path; it uses the proper app
Keychain identity.
-
Result: ciphertext encrypted under the old/wrong Keychain identity cannot be decrypted after upgrading.
-
Affects stored secrets such as GitHub token, MCP OAuth state, provider API keys, etc.
-
For OAuth tokens, practical recovery is usually reconnecting. A true migration would need an Electron 40/41 bridge build or a
native macOS Keychain migration helper.
We're analyzing why our test suite didn't catch these issues.
Dyad v1.6 upgraded Electron from v40 to Electron v43 which introduced/exposed two separate regressions:
GitHub device flow fails at /login/device/code
Dyad uses node-fetch@2.7.0.
GitHub returns a valid 200 response with content-encoding: gzip and transfer-encoding: chunked.
In Electron 43, node-fetch@2 misfires its chunked-response “Premature close” heuristic and errors while reading the body.
Confirmed:
Likely fix direction: avoid node-fetch@2 for this path, use native fetch/Undici or another HTTP client.
Existing safeStorage-encrypted secrets become unreadable
Electron 40 could touch macOS safeStorage before app.ready, which could initialize Keychain under the wrong identity: Chromium
Safe Storage.
Electron 43 changed safeStorage behavior and no longer uses that old pre-ready initialization path; it uses the proper app
Keychain identity.
Result: ciphertext encrypted under the old/wrong Keychain identity cannot be decrypted after upgrading.
Affects stored secrets such as GitHub token, MCP OAuth state, provider API keys, etc.
For OAuth tokens, practical recovery is usually reconnecting. A true migration would need an Electron 40/41 bridge build or a
native macOS Keychain migration helper.
We're analyzing why our test suite didn't catch these issues.