Summary
"Continue where you left off" never restores tabs. The preference is applied and persisted correctly, but profile.exit_type in Default/Preferences is stuck at Crashed even after a fully graceful quit, so every launch is treated as recovery-from-crash and session restore is skipped.
Session data is written to Default/Sessions/Tabs_* — it is simply never replayed.
Environment
|
|
| BrowserOS |
0.47.18 (CFBundleVersion 10000.0.47.18.0) |
| macOS |
26.5.2 (build 25F84) |
| Arch |
arm64 |
Steps to reproduce
- Settings → On startup → select Continue where you left off.
- Open a normal tab, e.g.
https://example.com.
- Quit BrowserOS gracefully (
osascript -e 'quit app "BrowserOS"', or Cmd-Q). Wait for the process to fully exit.
- Relaunch.
Expected: https://example.com is restored.
Actual: only chrome://newtab/ opens. The previous session's tabs are gone.
Ran this cycle four times with the same result each time.
The preference itself is fine
It is a protected pref, correctly written to Default/Secure Preferences with a valid MAC:
"session": { "restore_on_startup": 1 },
"protection": { "macs": { "session": {
"restore_on_startup": "82703D75AEB6…"
} } }Re-reading chrome://settings/onStartup after a reload shows the radio still selected, and the live pref object reports restore_on_startup: 1. So this is not a pref-persistence problem.
The actual signal
Default/Preferences after a graceful quit, with the process confirmed exited:
profile.exit_type = Crashed
Chromium normally writes exit_type = Normal on clean shutdown and only auto-restores when the prior exit was clean. Here it never flips, which is consistent with the clean-shutdown path not running. profile.exited_cleanly is absent entirely.
Meanwhile the session files are current and non-trivial:
Default/Sessions/Tabs_13432083436358941 329857 bytes (written at quit)
Not launch-method dependent
I first hit this with the app started by a launchd LaunchAgent execing the binary directly, and assumed that was the cause (no LaunchServices app lifecycle). It is not — I reproduced the identical behaviour with a plain:
open -a /Applications/BrowserOS.app
Same result under both: exit_type stays Crashed, no restore.
Note
This makes BrowserOS lossy across every restart for users who rely on session restore, which is especially noticeable when the app is configured to start at login.
Summary
"Continue where you left off" never restores tabs. The preference is applied and persisted correctly, but
profile.exit_typeinDefault/Preferencesis stuck atCrashedeven after a fully graceful quit, so every launch is treated as recovery-from-crash and session restore is skipped.Session data is written to
Default/Sessions/Tabs_*— it is simply never replayed.Environment
CFBundleVersion10000.0.47.18.0)Steps to reproduce
https://example.com.osascript -e 'quit app "BrowserOS"', or Cmd-Q). Wait for the process to fully exit.Expected:
https://example.comis restored.Actual: only
chrome://newtab/opens. The previous session's tabs are gone.Ran this cycle four times with the same result each time.
The preference itself is fine
It is a protected pref, correctly written to
Default/Secure Preferenceswith a valid MAC:Re-reading
chrome://settings/onStartupafter a reload shows the radio still selected, and the live pref object reportsrestore_on_startup: 1. So this is not a pref-persistence problem.The actual signal
Default/Preferencesafter a graceful quit, with the process confirmed exited:Chromium normally writes
exit_type = Normalon clean shutdown and only auto-restores when the prior exit was clean. Here it never flips, which is consistent with the clean-shutdown path not running.profile.exited_cleanlyis absent entirely.Meanwhile the session files are current and non-trivial:
Not launch-method dependent
I first hit this with the app started by a launchd LaunchAgent execing the binary directly, and assumed that was the cause (no LaunchServices app lifecycle). It is not — I reproduced the identical behaviour with a plain:
Same result under both:
exit_typestaysCrashed, no restore.Note
This makes BrowserOS lossy across every restart for users who rely on session restore, which is especially noticeable when the app is configured to start at login.