Query works manually, not from stored procedure - Safe update error
Right From the MySQL 8.0 Docs

It is possible for UPDATE and DELETE statements to produce an error in safe-updates mode even with a key specified in the WHERE clause, if the optimizer decides not to use the index on the key column:

Range access on the index cannot be used if memory usage exceeds that permitted by the range_optimizer_max_mem_size system variable. The optimizer then falls back to a table scan. See Limiting Memory Use for Range Optimization.

If key comparisons require type conversion, the index may not be used (see Section 8.3.1, “How MySQL Uses Indexes”). Suppose that an indexed string column c1 is compared to a numeric value using WHERE c1 = 2222. For such comparisons, the string value is converted to a number and the operands are compared numerically (see Section 12.3, “Type Conversion in Expression Evaluation”), preventing use of the index. If safe-updates mode is enabled, an error occurs.



As of MySQL 8.0.13, safe-updates mode also includes these behaviors:


EXPLAIN with UPDATE and DELETE statements does not produce safe-updates errors. This enables use of EXPLAIN plus SHOW WARNINGS to see why an index is not used, which can be helpful in cases such as when a range_optimizer_max_mem_size violation or type conversion occurs and the optimizer does not use an index even though a key column was specified in the WHERE clause.

When a safe-updates error occurs, the error message includes the first diagnostic that was produced, to provide information about the reason for failure. For example, the message may indicate that the range_optimizer_max_mem_size value was exceeded or type conversion occurred, either of which can preclude use of an index.

For multiple-table deletes and updates, an error is produced with safe updates enabled only if any target table uses a table scan.



Based on the these things, you need to run this
select @@global.sql_safe_updates,@@session.sql_safe_updates;

If your output shows 1 for @@global.sql_safe_updates,

mysqld process was started up with sql_safe_updates or i-am-a-dummy.
Otherwise, it was not started that way.

If your output shows 0 for @@session.sql_safe_updates, that means your client is setting it

The client will automatically have @@session.sql_safe_updates set to whatever is in @@global.sql_safe_updates
If the client has @@session.sql_safe_updates set to something different from @@global.sql_safe_updates, then the client is personally setting it.

The fact that you can execute it by hand shows that the client program you are using to connect allows you to run the query. You may need to review the setting in MySQL Workbench to see if --safe-updates is being imposed on stored procedure. Other than these things, please check out suggestions from StackOverflow on how to tweek safe-updates off and on in the Workbench.