# Recover When Oysterun Shows A Host Runtime Error

This guide helps you respond when Oysterun shows a Host runtime error instead of hiding it or continuing as if nothing happened. Use it to decide whether you can fix the problem yourself, retry the action, or collect the right information for support.

Host runtime errors usually mean Oysterun could not safely read required settings, save runtime state, complete a request, or keep the Host process running. Oysterun should show a bounded error message so you know what failed and what to do next.

## Before You Start

Start from the Oysterun Host page, a visible error banner, or the terminal where you normally manage the Host.

You need:

- access to the computer or server running the Oysterun Host
- permission to read the Host settings and logs
- the action you were trying when the error appeared
- a way to restart the Host only after you have saved the visible error details

If the Host page is unavailable, start from the terminal on the Host computer and use the service logs as the visible source of truth.

## Read The Visible Error

1. Open the Oysterun Host page.
2. Read the error banner, dialog, or failed request message.
3. Note the file name, setting name, or action named by the message.

Expected result: the error should name a bounded failure such as an invalid settings file, a save failure, a failed request, unavailable runtime status, or a last-resort Host crash report. It should not expose passwords, tokens, cookies, or private capability links.

Success checkpoint: you can describe the failing action and the visible error without guessing from hidden implementation details.

## Fix Invalid Settings

If the error names an invalid settings file:

1. Open the named settings file on the Host computer.
2. Fix broken JSON syntax, missing quotes, trailing commas, or a value that Oysterun says is not valid.
3. Save the file.
4. Restart or refresh the Host using your normal Host management path.

Expected result: the Host starts or refreshes without the same settings parse error.

Success checkpoint: the Host page opens and the previous settings error is gone. If a new setting is named, fix that new setting before retrying the original action.

## Retry A Failed Host Action

If the Host page is still running but one action failed:

1. Return to the screen where the action failed.
2. Retry the same action once.
3. Watch whether the same error appears again.

Expected result: temporary write or request failures may clear on retry. Required settings errors will usually return until the setting is fixed.

Success checkpoint: the action either completes, or the same bounded error returns with enough detail to identify the next recovery step.

## Check Host Runtime Status

Use Host runtime status when you need to know whether the Host is running with readable status information.

1. Open the Host page.
2. Open the available status, preferences, or service view for the Host.
3. Look for the current Host status and any runtime metadata warning.

Expected result: the status view should show whether runtime information is available. If status information is missing or unreadable, Oysterun should say that plainly instead of presenting stale information as current.

Success checkpoint: you know whether the Host is running, whether runtime status is readable, and whether you need to restart the Host or inspect logs.

## Use Service Logs When The Page Will Not Open

If the Host page will not load:

1. Open a terminal on the Host computer.
2. Run the service log command for your installation.
3. Look for the newest Host runtime error near the time the page stopped loading.

Expected result: the log should show the same kind of bounded failure: invalid settings, failed runtime save, failed request handling, unreadable runtime status, or a last-resort crash diagnostic.

Success checkpoint: you have the newest error message and timestamp before you restart or change settings.

## Recover Safely

If the same error continues after one retry:

1. Save the visible error text, timestamp, and the action that triggered it.
2. Fix only the setting or file named by the error.
3. Restart the Host only after you have saved the error details.
4. Retry the original action.

Expected result: a settings or file problem should clear after the named item is fixed. A repeated crash or repeated failed request should be treated as a support issue with the saved details.

If the error mentions private data, copy only the safe parts of the message: the error class, file name without private folder details when possible, timestamp, and visible action. Do not share passwords, tokens, cookies, or full private paths in public reports.

## When To Stop

Stop retrying and collect support details when:

- the Host exits again after restart
- the same action fails with the same error more than once
- the error says runtime status is missing or unreadable after a restart
- the error would require editing a file you do not own
- the message includes private information you are not sure how to redact

Expected result: support can use the saved visible error, timestamp, and action name to identify the next step without needing your credentials or private browser state.