Bug: Multiple 404 Not Found errors for /config/read on startup #3679
Description
Describe the bug
On startup, the Goose desktop application frequently shows multiple 404 Not Found errors for network requests to the /config/read endpoint. This happens on a dynamically allocated port (e.g., 127.0.0.1:64470) which changes with each application session.
I am reporting this because these errors suggest a potential timing issue during the app's initialization.
To Reproduce
Steps to reproduce the behavior:
- Ensure you have a clean session (quit the application completely).
- Open the Goose desktop application.
- Open the developer tools (using
Cmd+Option+Ion macOS orCtrl+Shift+Ion Windows/Linux). - Navigate to the "Console" and "Network" tabs.
- Observe the logs upon startup. You will see several
Failed to load resource: the server responded with a status of 404 (Not Found)errors for the/config/readendpoint.
Expected behavior
The application should start up cleanly without any 404 errors. All necessary configuration should be read successfully on the first attempt, allowing the application to initialize correctly and display the main chat or welcome view.
Screenshots
The following screenshot of the developer console illustrates the issue, showing the sequence of initialization logs followed by multiple failed requests to /config/read:
View Screenshots
Please provide the following information:
- OS & Arch: macOS
- Interface: UI
- Version: 1.1.4
- Extensions enabled: Default built-in extensions (the issue occurs before sending the first message)
- Provider & Model (1/3): OpenRouter / Google Gemini2.5, Claude 3.7 (as observed in logs, but the issue is provider-agnostic).
- Provider & Model (2/3): Anthropic / Claude 3.7 (issue is provider-agnostic).
- Provider & Model (3/3): OpenAI / o4-mini (issue is provider-agnostic).
Additional context 🪿🕵🏻♂️
Further Observations and Console Logs
Here are a few additional observations Goose made, that might be helpful for debugging:
- Dynamic Port Allocation: The backend
goosedprocess is started on a random, available port for each new application window. The frontend is correctly configured to communicate with this port. - Race Condition: The errors occur because multiple components in the frontend (
App.tsx) attempt to read configuration settings concurrently during the initialuseEffecthook. The console logSetting up extension handlerappears immediately before the errors, pointing to the initialization of extensions as a primary trigger. - Root Cause: The core problem is that these configuration requests are fired off without waiting for the backend server to be fully initialized and ready to serve requests. This results in the server returning 404s because it's not yet able to handle the
/config/readroute when the requests arrive. The multiple, simultaneousread()calls from different parts of the initialization code exacerbate the problem.