I'm running a self-hosted Dify 1.14 stack (docker-compose) and hit a confusing failure mode while cloning an agent-chat app. Putting it here in case it's useful or worth fixing.

What happens

I have a Custom Tool that was originally registered with one operation (op_a). I attached it to an agent-chat app, so model_config.agent_mode.tools for that app has op_a listed.

Later I updated the Custom Tool's OpenAPI schema to add a second operation (op_b) and re-imported it. The workspace tool list now shows the Custom Tool exposes both operations. Good.

But — the original app I attached the tool to still has only op_a in its tools list. New operations don't auto-attach to apps that already use the tool. Fine on its own, that's defensible behavior.

The problem is what happens when I clone that app. The clone gets agent_mode.tools copied verbatim, so the clone also only has op_a. The UI shows the Custom Tool attached and the model sees one operation. If I then prompt the agent to use op_b by name, it narrates "I will use op_b first..." and then actually invokes op_a with op_b's parameters, which errors out.

So functionally op_b is missing from the clone, even though the provider exposes it.

Repro

1. Create a Custom Tool from an OpenAPI spec with one operation op_a.
2. Create an agent-chat app, attach the tool. agent_mode.tools = [op_a].
3. Edit the Custom Tool's OpenAPI to add op_b, re-import. Workspace tool now shows both operations available.
4. POST /console/api/apps/{src_id}/copy to clone the app.
5. GET /console/api/apps/{new_id} and look at model_config.agent_mode.tools.
6. Clone has only op_a. op_b is not there, even though it exists on the provider.

Why it's confusing

There's no visible indicator that the clone has a stale tool attachment. The tool icon shows up in the tool list, the model gets one operation, the UI looks normal. But the model can't reach op_b.

The user-facing failure looks like a model bug. The agent says "I will use op_b first" and then doesn't, or calls op_a with op_b's args. I spent a few hours debugging this as if it was a model orchestration issue — token budget pressure, agent-loop iteration limit, sampling temperature — before I realised the tool just wasn't attached. The narration was the model literally telling me it wanted to call a tool it didn't have, which is how an agent should behave when instructed to use a tool that isn't in it's tool list.

Workaround

After cloning, read the source app's agent_mode.tools, deep-copy the existing entry shape, mutate tool_name + tool_parameters to match the new operation, append, then POST back via /console/api/apps/{new_id}/model-config. ~5 lines of patching. Doable but it's a footgun.

Suggested fixes

A few options, increasing in scope:

• Lowest: surface a warning on the app's tool-config UI when the attached operations are a subset of what the provider exposes. Something like "Tool X has 3 operations in the workspace, this app uses 1. Manage attachments?"
• Medium: when cloning, re-resolve every attached Custom Tool against its current provider state and pull in all operations available now. (Would change clone semantics — might be controversial since it makes clones non-faithful copies.)
• Most upstream: when re-importing a Custom Tool with new operations, prompt "auto-attach op_b to N existing apps that already use this tool?"

I'd be happy with any of them. Right now the lack of any signal is what burns time.

Happy to put together a PR if there's a preferred approach — let me know.