Exec tool not found | Friends of the Crustacean 🦞🤝 | Page 1

outer cloud Apr 13, 2026, 3:22 AM

#

My agent is telling me that it cant perform shell task. I have this set in openclaw.json

"tools": {
    "profile": "coding",
    "exec": {
      "host": "gateway",
      "security": "full",
      "ask": "off"
    }

What's the issue?

analog sleetBOT Apr 13, 2026, 3:22 AM

#

simple scrollBOT Apr 13, 2026, 3:22 AM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

analog sleetBOT Apr 13, 2026, 3:22 AM

#

errant sluiceBOT Apr 13, 2026, 3:24 AM

#

That snippet by itself looks fine.

tools.profile: "coding" already includes exec and process, and tools.exec.host/security/ask only control how exec runs, not whether the tool is available.

So if the agent still says it cannot do shell tasks, the usual issue is one of these:

Gateway wasn’t restarted after changing config
openclaw gateway restart
Another tool policy is overriding it
- tools.allow
- tools.deny
- tools.byProvider
- agents.list[].tools.*
- tools.sandbox.tools.*
You’re using an ACP agent, not the normal embedded agent

#

ACP has a separate permission layer. If logs show
AcpRuntimeError: Permission prompt unavailable in non-interactive mode
then set:

"plugins": {
  "entries": {
    "acpx": {
      "config": {
        "permissionMode": "approve-all"
      }
    }
  }
}

then restart the gateway.

First thing, can you paste:

#

openclaw --version
openclaw config get tools
openclaw sandbox explain

If it’s ACP-based, also paste:

openclaw config get plugins.entries.acpx.config

Docs:

outer cloud Apr 13, 2026, 3:25 AM

#

OpenClaw 2026.4.9 (0512059)


{
  "profile": "coding",
  "allow": [
    "group:web",
    "cron",
    "pdf"
  ],
  "deny": [
    "nodes",
    "canvas",
    "tts",
    "message"
  ],
  "exec": {
    "host": "gateway",
    "security": "full",
    "ask": "off"
  }
}

Effective sandbox:
  agentId: main
  sessionKey: agent:main:main
  mainSessionKey: agent:main:main
  runtime: direct
  mode: off scope: agent
  workspaceAccess: none workspaceRoot: /Users/openclaw/.openclaw/sandboxes

Sandbox tool policy:
  allow (default): exec, process, read, write, edit, apply_patch, image, sessions_list, sessions_history, sessions_send, sessions_spawn, sessions_yield, subagents, session_status
  deny  (default): browser, canvas, nodes, cron, gateway, feishu, googlechat, nostr, msteams, mattermost, nextcloud-talk, matrix, bluebubbles, line, zalo, zalouser, synology-chat, tlon, qa-channel, discord, imessage, irc, qqbot, signal, slack, telegram, twitch, whatsapp

Elevated:
  enabled: true
  channel: webchat
  allowedByConfig: false
  failing gates: allowFrom (tools.elevated.allowFrom.webchat)

errant sluiceBOT Apr 13, 2026, 3:26 AM

#

Yep, the problem is your tools.allow.

With this:

"allow": [
  "group:web",
  "cron",
  "pdf"
]

you turned tool policy into a restrictive allowlist, so everything not in that list is blocked, including exec.

So even though profile: "coding" includes exec, your allow overrides that and removes it.

Fix

#

Either remove allow entirely, or change it to additive alsoAllow.

This is probably what you want:

{
  tools: {
    profile: "coding",
    alsoAllow: ["pdf"],
    deny: ["nodes", "canvas", "tts", "message"],
    exec: {
      host: "gateway",
      security: "full",
      ask: "off"
    }
  }

#

Notes:

group:web is already in coding
cron is already in coding
exec is already in coding
pdf is the only extra one you seem to need

Then restart:

openclaw gateway restart

So, short version: the issue is not tools.exec, it’s tools.allow.

#

Docs: https://docs.openclaw.ai/gateway/configuration-reference

If that fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it. 🎉

outer cloud Apr 13, 2026, 4:46 AM

#

Thanks. What's the best way to set up a new agent with its own workspace? The last time I attempted to do it, it wiped out my existing agent's workspace and replaced all the files.

errant sluiceBOT Apr 13, 2026, 4:47 AM

#

Best practice is:

one unique workspace per agent
one unique agentDir per agent
never reuse the same workspace path for two agents

What probably happened last time is the new agent was pointed at the same workspace as the old one, so bootstrap/files looked like they got “replaced”.

Safe way

Use the agent helper and give it a brand new workspace:

openclaw agents add work --workspace ~/.openclaw/workspace-work

That gives you:

#

main → ~/.openclaw/workspace
work → ~/.openclaw/workspace-work

and its own agent state under:

~/.openclaw/agents/work/agent

Good config shape

{
  agents: {
    list: [
      {
        id: "main",
        default: true,
        workspace: "~/.openclaw/workspace"

#

      },
      {
        id: "work",
        workspace: "~/.openclaw/workspace-work"
      }
    ]
  }
}

Important gotchas

Don’t point agents.list[].workspace for two agents at the same folder.
Don’t reuse agentDir either.
Be careful with agents.defaults.workspace, that’s the fallback for agents that don’t set their own workspace.

#

If you want to clone an existing agent

Copy the old workspace to a new folder, then point the new agent there. Don’t bind the new agent to the original workspace path.

Verify

openclaw agents list --bindings

Docs:

If you want, paste your current agents section and I can sanity-check it before you create the new one.

outer cloud Apr 13, 2026, 4:51 AM

#

This is my openclaw folder structure now. charlotte is the only agent I use and is working now.


├── exec-approvals.json (181 B)
├── openclaw.json (6.1 KB)
├── openclaw.json.bak (6.1 KB)
├── openclaw.json.bak.1 (6.0 KB)
├── openclaw.json.bak.2 (6.0 KB)
├── openclaw.json.bak.3 (6.0 KB)
├── openclaw.json.bak.4 (6.0 KB)
├── update-check.json (189 B)
├── telegram/
├── devices/
├── charlotte-workspace/
├── tasks/
├── flows/
├── logs/
├── qqbot/
├── credentials/
├── identity/
├── memory/
├── completions/
├── cron/
├── canvas/
├── workspace/
├── media/
├── workspace-jarvis/
├── agents/
├── delivery-queue/
└── browser/

errant sluiceBOT Apr 13, 2026, 4:52 AM

#

That structure is okay, but I can see the trap right away: you have three workspace-looking folders:

charlotte-workspace/
workspace/
workspace-jarvis/

That’s exactly how people accidentally point two agents at the wrong place.

The rule that keeps you safe

Don’t rely on folder names.
Rely on explicit agent config:

agents.defaults.workspace = fallback only
agents.list[].workspace = what each agent actually uses

What I’d do

#

Make sure every real agent has its own explicit workspace.

For example:

{
  agents: {
    list: [
      {
        id: "charlotte",
        default: true,
        workspace: "~/.openclaw/charlotte-workspace"
      },
      {
        id: "jarvis",
        workspace: "~/.openclaw/workspace-jarvis"

#

      }
    ]
  }
}

That way:

Charlotte only touches charlotte-workspace
Jarvis only touches workspace-jarvis
the generic workspace/ folder can stay untouched until you confirm whether it’s still used

Important

If charlotte does not have its own workspace set, it may be inheriting agents.defaults.workspace, which is often ~/.openclaw/workspace. That’s where confusion starts.

Best next check

#

Paste this:

openclaw config get agents

That’ll show exactly which folder each agent is actually using.
I’d avoid deleting workspace/ or anything else until that is clear.

Docs:

If you paste your agents section, I can tell you the exact safe config in one shot.

outer cloud Apr 13, 2026, 4:53 AM

#

{
  "defaults": {
    "model": {
      "primary": "zai/glm-5",
      "fallbacks": [
        "zai/glm-4.7",
        "zai/glm-4.6",
        "google/gemini-3-flash-preview",
        "anthropic/claude-sonnet-4-6"
      ]
    },
    "models": {
      "google/gemini-3-flash-preview": {
        "alias": "gemini-flash"
      },
      "anthropic/claude-3-7-sonnet-latest": {},
      "anthropic/claude-sonnet-4-6": {
        "alias": "sonnet"
      },
      "zai/glm-5": {
        "alias": "GLM"
      },
      "zai/glm-4.7": {},
      "zai/glm-4.6": {},
      "zai/glm-4.5-air": {}
    },
    "workspace": "/Users/openclaw/.openclaw/charlotte-workspace",
    "contextPruning": {
      "mode": "cache-ttl",
      "ttl": "1h"
    },
    "compaction": {
      "mode": "safeguard",
      "reserveTokensFloor": 30000
    },
    "timeoutSeconds": 1800,
    "heartbeat": {
      "every": "30m"
    },
    "maxConcurrent": 4,
    "subagents": {
      "maxConcurrent": 8
    }
  },
  "list": [
    {
      "id": "main",
      "default": true,
      "model": "zai/glm-5",
      "skills": []
    }
  ]
}

errant sluiceBOT Apr 13, 2026, 4:54 AM

#

Aha, found the footgun.

Right now you do not have a separate charlotte agent. You only have:

agent id: main
workspace: /Users/openclaw/.openclaw/charlotte-workspace

And that workspace is set in:

agents.defaults.workspace

That means any new agent without its own explicit workspace will inherit Charlotte’s workspace.
That’s why it looked like the new agent “replaced” the old one.

Best fix

#

Don’t keep workspace in agents.defaults once you go multi-agent.
Set the workspace per agent.

Safer shape

{
  "agents": {
    "defaults": {
      "model": { ... },
      "contextPruning": { ... },
      "compaction": { ... },
      "timeoutSeconds": 1800,
      "heartbeat": { "every": "30m" },
      "maxConcurrent": 4,
      "subagents": { "maxConcurrent": 8 }

#

    },
    "list": [
      {
        "id": "main",
        "default": true,
        "workspace": "/Users/openclaw/.openclaw/charlotte-workspace",
        "model": "zai/glm-5",
        "skills": []
      },
      {
        "id": "jarvis",
        "workspace": "/Users/openclaw/.openclaw/workspace-jarvis",
        "model": "zai/glm-5"
      }
    ]

#

}
}

Short version

agents.defaults.workspace = dangerous once you add more agents
agents.list[].workspace = the safe way
workspace-jarvis/ is fine, but only if jarvis explicitly points to it

Easiest path

If you use the CLI, do this:

#

openclaw agents add jarvis --workspace /Users/openclaw/.openclaw/workspace-jarvis

Then make sure main also has its workspace explicitly set, instead of relying on defaults.workspace.

After editing config:

openclaw gateway restart

Docs:

#

Glad we caught that, it’s a really easy one to trip over. If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

outer cloud Apr 13, 2026, 5:04 AM

#

Can I get directions to cleanup my workspace now just to run a single agent (Charlotte), but with the ability to add one another agent later.

errant sluiceBOT Apr 13, 2026, 5:05 AM

#

Yep. I’d clean it up like this, nice and safe.

1. Make Charlotte explicit

Right now Charlotte is your main agent, so I’d switch from:

agents.defaults.workspace = /Users/openclaw/.openclaw/charlotte-workspace

to this:

{
  "agents": {
    "defaults": {
      // keep your shared defaults here, but no workspace
    },

#

    "list": [
      {
        "id": "main",
        "default": true,
        "workspace": "/Users/openclaw/.openclaw/charlotte-workspace",
        "model": "zai/glm-5",
        "skills": []
      }
    ]
  }
}

Why: later, if you add another agent, it won’t inherit Charlotte’s workspace by accident.

2. Restart and verify

#

openclaw gateway restart
openclaw status
openclaw config get agents

You want to confirm main is explicitly using:

/Users/openclaw/.openclaw/charlotte-workspace

3. Keep these

I would keep:

openclaw.json
agents/

#

charlotte-workspace/
credentials/
channel folders like telegram/, qqbot/
logs/, media/, tasks/, flows/

4. Likely safe to archive/trash later

After you verify config is clean, these look like old leftovers:

workspace/
workspace-jarvis/

I would move them to Trash, not hard delete.

5. Optional cleanup

These are usually fine to keep, but optional:

openclaw.json.bak*

#

6. When you want a second agent later

Add it with its own explicit workspace:

openclaw agents add jarvis --workspace /Users/openclaw/.openclaw/workspace-jarvis

That’s the whole trick.

Recommended end state

one live agent: main
one live workspace: charlotte-workspace
no workspace in agents.defaults
future agents always get their own agents.list[].workspace

#

Docs:

If you want, paste your full agents block after you edit it and I’ll do a quick sanity check.

outer cloud Apr 13, 2026, 6:23 AM

#

Just added workspace to "list" and restarted gateway. Does this look right?

{
  "defaults": {
    "model": {
      "primary": "zai/glm-5",
      "fallbacks": [
        "zai/glm-4.7",
        "zai/glm-4.6",
        "google/gemini-3-flash-preview",
        "anthropic/claude-sonnet-4-6"
      ]
    },
    "models": {
      "google/gemini-3-flash-preview": {
        "alias": "gemini-flash"
      },
      "anthropic/claude-3-7-sonnet-latest": {},
      "anthropic/claude-sonnet-4-6": {
        "alias": "sonnet"
      },
      "zai/glm-5": {
        "alias": "GLM"
      },
      "zai/glm-4.7": {},
      "zai/glm-4.6": {},
      "zai/glm-4.5-air": {}
    },
    "workspace": "/Users/openclaw/.openclaw/charlotte-workspace",
    "contextPruning": {
      "mode": "cache-ttl",
      "ttl": "1h"
    },
    "compaction": {
      "mode": "safeguard",
      "reserveTokensFloor": 30000
    },
    "timeoutSeconds": 1800,
    "heartbeat": {
      "every": "30m"
    },
    "maxConcurrent": 4,
    "subagents": {
      "maxConcurrent": 8
    }
  },
  "list": [
    {
      "id": "main",
      "default": true,
      "model": "zai/glm-5",
      "skills": []
    }
  ]
}

errant sluiceBOT Apr 13, 2026, 6:23 AM

#

Not quite, the workspace is still under defaults, not under list.

Right now it still says:

"defaults": {
  ...
  "workspace": "/Users/openclaw/.openclaw/charlotte-workspace"
}

So a future new agent would still inherit Charlotte’s workspace.

What you want instead

#

{
  "defaults": {
    "model": {
      "primary": "zai/glm-5",
      "fallbacks": [
        "zai/glm-4.7",
        "zai/glm-4.6",
        "google/gemini-3-flash-preview",
        "anthropic/claude-sonnet-4-6"
      ]
    },
    "models": {
      "google/gemini-3-flash-preview": { "alias": "gemini-flash" },
      "anthropic/claude-3-7-sonnet-latest": {},
      "anthropic/claude-sonnet-4-6": { "alias": "sonnet" },

#

      "zai/glm-5": { "alias": "GLM" },
      "zai/glm-4.7": {},
      "zai/glm-4.6": {},
      "zai/glm-4.5-air": {}
    },
    "contextPruning": {
      "mode": "cache-ttl",
      "ttl": "1h"
    },
    "compaction": {
      "mode": "safeguard",
      "reserveTokensFloor": 30000
    },
    "timeoutSeconds": 1800,
    "heartbeat": {

#

      "every": "30m"
    },
    "maxConcurrent": 4,
    "subagents": {
      "maxConcurrent": 8
    }
  },
  "list": [
    {
      "id": "main",
      "default": true,
      "workspace": "/Users/openclaw/.openclaw/charlotte-workspace",
      "model": "zai/glm-5",
      "skills": []
    }

#

]
}

The key change

remove defaults.workspace
add list[0].workspace

Then restart again:

openclaw gateway restart

So, close, but one more move and you’re good.

outer cloud Apr 13, 2026, 6:24 AM

#

How do I make this key change? in openclaw.json?

errant sluiceBOT Apr 13, 2026, 6:24 AM

#

Yep, in openclaw.json.

Easiest way is via CLI:

openclaw config set agents.list[0].workspace "/Users/openclaw/.openclaw/charlotte-workspace"
openclaw config unset agents.defaults.workspace
openclaw gateway restart

Since main is your first and only agent right now, agents.list[0] is the right one.

Then verify:

openclaw config get agents --json

#

You should end up with workspace under the main agent entry, and no defaults.workspace.

If you prefer editing by hand, make these exact changes in ~/.openclaw/openclaw.json:

remove:

"workspace": "/Users/openclaw/.openclaw/charlotte-workspace"

from defaults

add:

"workspace": "/Users/openclaw/.openclaw/charlotte-workspace"

inside the main object in list

If you paste the updated block after that, I’ll sanity-check it.

outer cloud Apr 13, 2026, 6:25 AM

#

Getting this error: openclaw@openclaws-Mac-mini ~ % openclaw config set agents.list[0].workspace "/Users/openclaw/.openclaw/charlotte-workspace"
zsh: no matches found: agents.list[0].workspace

errant sluiceBOT Apr 13, 2026, 6:25 AM

#

Yep, that’s just zsh eating the [].

Quote the config path:

openclaw config set 'agents.list[0].workspace' "/Users/openclaw/.openclaw/charlotte-workspace"
openclaw config unset 'agents.defaults.workspace'
openclaw gateway restart

Why: in zsh, [0] is treated like a glob pattern unless you quote it.

Then verify:

openclaw config get agents --json

#

You should see workspace under the main agent entry. If you want, paste that output and I’ll check it.

outer cloud Apr 13, 2026, 6:26 AM

#

Like this?

openclaw@openclaws-Mac-mini ~ % openclaw config get agents --json

{
  "defaults": {
    "model": {
      "primary": "zai/glm-5",
      "fallbacks": [
        "zai/glm-4.7",
        "zai/glm-4.6",
        "google/gemini-3-flash-preview",
        "anthropic/claude-sonnet-4-6"
      ]
    },
    "models": {
      "google/gemini-3-flash-preview": {
        "alias": "gemini-flash"
      },
      "anthropic/claude-3-7-sonnet-latest": {},
      "anthropic/claude-sonnet-4-6": {
        "alias": "sonnet"
      },
      "zai/glm-5": {
        "alias": "GLM"
      },
      "zai/glm-4.7": {},
      "zai/glm-4.6": {},
      "zai/glm-4.5-air": {}
    },
    "contextPruning": {
      "mode": "cache-ttl",
      "ttl": "1h"
    },
    "compaction": {
      "mode": "safeguard",
      "reserveTokensFloor": 30000
    },
    "timeoutSeconds": 1800,
    "heartbeat": {
      "every": "30m"
    },
    "maxConcurrent": 4,
    "subagents": {
      "maxConcurrent": 8
    }
  },
  "list": [
    {
      "id": "main",
      "default": true,
      "workspace": "/Users/openclaw/.openclaw/charlotte-workspace",
      "model": "zai/glm-5",
      "skills": []
    }
  ]
}

errant sluiceBOT Apr 13, 2026, 6:26 AM

#

Yep, that looks right ✅

You now have:

no agents.defaults.workspace
main explicitly pinned to:
/Users/openclaw/.openclaw/charlotte-workspace

That’s the future-proof setup for:

running just Charlotte now
adding another agent later without inheriting Charlotte’s workspace

When you eventually add a second agent, just give it its own workspace, for example:

openclaw agents add jarvis --workspace /Users/openclaw/.openclaw/workspace-jarvis

#

At this point, workspace/ and workspace-jarvis/ are probably just leftovers unless something else references them, so don’t rush to delete them, but you’re out of the danger zone now.

Glad we got it sorted. If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it. 🎉

outer cloud Apr 13, 2026, 6:28 AM

#

how can I delete those workspaces using cli?

errant sluiceBOT Apr 13, 2026, 6:29 AM

#

For configured agents, use:

openclaw agents delete <agent-id>

That moves the agent’s workspace/state/sessions to Trash, not hard-delete.
But in your case, workspace/ and workspace-jarvis/ look like orphan folders, not active agents.

So for those, there isn’t a dedicated OpenClaw workspace-delete command. Use trash from the CLI:

trash ~/.openclaw/workspace ~/.openclaw/workspace-jarvis

Before you do that

Make sure your active config still points only to:

#

/Users/openclaw/.openclaw/charlotte-workspace

which it looks like it does now.

Do not trash

~/.openclaw/charlotte-workspace
~/.openclaw/agents

Nice extra check

openclaw doctor

That can warn about extra workspace dirs too.

#

So short version:

real agent → openclaw agents delete <id>
leftover folder → trash <path>

If you want, I can help you sanity-check exactly which folders are safe to trash from your current tree.

outer cloud Apr 13, 2026, 8:29 AM

#

Placed those two folders to trash. Ran openclaw doctor and got this:

Gateway Recommendation:

Recommendation: run a single gateway per machine for most setups. │
│ One gateway supports multiple agents. │
│ If you need multiple gateways (e.g., a rescue bot on the same host), isolate ports + │
│ config/state (see docs: /gateway#multiple-gateways-same-host).

Gateway service config:

│ - Gateway service entrypoint does not match the current install. │
│ (/opt/homebrew/lib/node_modules/openclaw/dist/entry.js -> │
│ /opt/homebrew/lib/node_modules/openclaw/dist/index.js) │

errant sluiceBOT Apr 13, 2026, 8:30 AM

#

That first “single gateway per machine” bit is just a general recommendation, not an error.

The real issue is this one:

Gateway service entrypoint does not match the current install
dist/entry.js -> dist/index.js

That usually means your macOS LaunchAgent/service is still pointing at an old OpenClaw entry file after an upgrade.

Fix

Simplest repair:

openclaw gateway install --force
openclaw gateway restart

#

Then verify:

openclaw gateway status
openclaw doctor

Alternative

Doctor can repair it too:

openclaw doctor --repair

What this means

#

Your install is current, but the service definition is stale.

Docs:

If you paste the output of openclaw gateway status after that, I can confirm you’re clean.

outer cloud Apr 13, 2026, 8:31 AM

#

Clean or not?

Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-13.log
Command: /opt/homebrew/opt/node@22/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/entry.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 42587, state active)
RPC probe: ok

Listening: 127.0.0.1:18789

errant sluiceBOT Apr 13, 2026, 8:31 AM

#

Functionally, yes, it looks healthy:

Runtime: running
RPC probe: ok
config paths match
gateway is listening on 127.0.0.1:18789

So from an uptime/health perspective, that’s good.

One nuance

Your service command still shows:

.../dist/entry.js

#

So if openclaw doctor is still warning about entry.js -> index.js, then it’s not fully clean from doctor’s point of view, even though the gateway is currently working.

My take

Working right now? yes
Doctor-perfect? maybe not yet

If you want to be sure, run openclaw doctor one more time:

if the warning is gone, you’re clean
if it still shows the entrypoint mismatch, run:

openclaw gateway install --force
openclaw gateway restart

#

If you paste the new openclaw doctor output, I can give you a straight yes/no.

outer cloud Apr 13, 2026, 8:32 AM

#

Will openclaw gateway install -- force ruin anything? Don't wanna mess it up.

errant sluiceBOT Apr 13, 2026, 8:32 AM

#

For your setup, it should be safe.

What openclaw gateway install --force does is basically:

rewrite the LaunchAgent/service file
point it at the current OpenClaw install
keep using your existing ~/.openclaw/openclaw.json

What it does not do:

delete your workspace
delete sessions
delete agent state
wipe your config

The real risk is mostly this:

it can overwrite custom service tweaks
it will briefly interrupt the gateway while you restart it

#Exec tool not found

Fix

Safe way

Good config shape

Important gotchas

If you want to clone an existing agent

Verify

The rule that keeps you safe

What I’d do

Important

Best next check

Best fix

Safer shape

Short version

Easiest path

1. Make Charlotte explicit

2. Restart and verify

3. Keep these

4. Likely safe to archive/trash later

5. Optional cleanup

6. When you want a second agent later

Recommended end state

What you want instead

The key change

Before you do that

Do not trash

Nice extra check

Fix

Alternative

What this means

One nuance

My take