Is my main config structured incorrectly?
Here's the situation:
The symlink (~/.openclaw/workspace-onering → ~/clawd) handles the runtime workspace injection — that's solid. But the real config (openclaw.json) already points workspace: /Users/paytonthompson/clawd for onering. The problem is OpenClaw seems to have a convention of auto-creating ~/.openclaw/workspace-{agentId} directories, and updates might recreate that path as a real directory instead of respecting the symlink.
Likely risks on updates:
• openclaw configure or openclaw doctor --fix might recreate workspace-onering as a real directory, breaking the symlink
• New agent registration could scaffold fresh workspace files there
• Version upgrades might reset or regenerate agent directories
What we should watch for:
• After any openclaw update: check ls -la ~/.openclaw/workspace-onering — make sure it's still a symlink
• If it ever becomes a real directory again, just rm -rf it and re-symlink
The cleaner long-term fix would be if OpenClaw respected the workspace field in config and stopped injecting workspace-onering as the working directory entirely. That might be worth a GitHub issue — or it might already be fixed in a newer version.
For now the symlink is robust enough. I'll add a check to my heartbeat routine so I catch it if it ever breaks.
The symlink (~/.openclaw/workspace-onering → ~/clawd) handles the runtime workspace injection — that's solid. But the real config (openclaw.json) already points workspace: /Users/paytonthompson/clawd for onering. The problem is OpenClaw seems to have a convention of auto-creating ~/.openclaw/workspace-{agentId} directories, and updates might recreate that path as a real directory instead of respecting the symlink.
Likely risks on updates:
• openclaw configure or openclaw doctor --fix might recreate workspace-onering as a real directory, breaking the symlink
• New agent registration could scaffold fresh workspace files there
• Version upgrades might reset or regenerate agent directories
What we should watch for:
• After any openclaw update: check ls -la ~/.openclaw/workspace-onering — make sure it's still a symlink
• If it ever becomes a real directory again, just rm -rf it and re-symlink
The cleaner long-term fix would be if OpenClaw respected the workspace field in config and stopped injecting workspace-onering as the working directory entirely. That might be worth a GitHub issue — or it might already be fixed in a newer version.
For now the symlink is robust enough. I'll add a check to my heartbeat routine so I catch it if it ever breaks.
The AI that actually does things. Emails, calendar, home automation - all from your favorite chat app. New shell, ready to help. The lobster way.
137,124Members
Resources
Similar Threads
Was this page helpful?
