Any progress with this? Starting to see the same in my 10.12.0 app, sporadically.

We are also facing the same issue. We are using studio pro version 10.12.3. We started getting this error after changing the version from 10.6.1 to 10.12.3 .

Please do not follow the recommendation to extend the SessionTimeout. This is not recommended and can negatively impact the performance of your Mendix application and can also have an impact on your billing.

We have identified an issue with session handling that was introduce in 10.9 and released a fix in 10.12.3. Please test if this version resolves the issue for you. If not, please reach out to our support, so we can investigate the issue and provide a fix.

We will soon release a feature to allow users to stay logged in beyond the lifetime of a session using authentication tokens. This is already used in offline-first PWAs and native mobile apps.

Hi,

This error:

Attempt to illegally change a value for object ... Object hash is invalid

is typically related to client–server state mismatch, and your observations (session idle, cookie clear fixing it, random entities, application-wide) strongly point to stale client data combined with stricter hash validation introduced in Mendix 10.9.

What is actually happening

From Mendix 10.9 onwards, object integrity validation (hash checking) became stricter as part of session/security improvements.

Each object sent to the client contains a hash. When the client sends changes back:

• Mendix verifies that the object has not been modified or invalidated
• If the hash does not match → this error is thrown

Why it happens in your case

Based on your description, the most likely causes are:

1. Stale session + cached client objects

• User leaves the app idle
• Session expires or is partially invalidated
• Browser still holds old objects (with old hashes)
• When user interacts again → client sends outdated object → hash mismatch

This explains:

• Happens after inactivity
• Cookie clear fixes it
• Not tied to a specific page/entity

2. Long-lived pages with non-persistent or context objects

If pages stay open for a long time:

• Context objects may be refreshed/changed on server
• Client still holds old reference

3. Background refresh / microflow updates

If objects are:

• Updated in background (microflows, scheduled events, nanoflows syncing)
• Or retrieved again with different state

Then client copy ≠ server copy → hash invalid

4. Multiple tabs / sessions

If the same user:

• Opens app in multiple tabs
• Or session gets renewed

Client state can go out of sync

Why it started after 10.9

Your assumption is correct.

Mendix 10.9 introduced:

• Stricter session/token handling
• Stronger validation of client data

So issues that were silently ignored earlier now throw this error.

Working Solutions

You won’t fix this with a single setting — you need to handle session + client refresh properly.

1. Force reload after inactivity

Implement a session timeout handler:

• Use JavaScript action or nanoflow to detect inactivity
• After timeout → redirect to homepage or reload page

Example approach:

window.location.reload();

This ensures stale objects are cleared.

2. Avoid long-lived pages with editable objects

• Do not keep pages open for long time with editable data
• Especially for:
  • Data views with context objects
  • Non-persistent objects

Instead:

• Reload data when user returns (on page show microflow)

3. Always refresh objects after server changes

In microflows:

• Use Refresh in Client = Yes

If not:

• Client keeps old object → hash mismatch later

4. Avoid reusing stale objects in nanoflows

If using nanoflows:

• Do not rely on previously loaded objects after long time
• Re-fetch using microflow if needed

5. Handle session expiration properly

Check your Project Settings → Runtime → Session timeout

Then:

• Align frontend behavior with session timeout
• Redirect user before session becomes invalid

6. ImportantCheck custom widgets / JS

If you are using:

• Custom React widgets
• JS actions

Ensure:

• You are not mutating objects manually
• You are not storing Mendix objects outside lifecycle

7. Temporary mitigation

• Clearing cookies works because it resets client state
• But this is not a real solution, only confirmation of root cause

• This is not a random bug — it is due to client-server state mismatch
• Triggered more frequently after Mendix 10.9 due to stricter validation
• Root cause: stale objects after session idle / refresh mismatch

Best fix:

• Handle session timeout properly
• Refresh/reload data when user returns
• Ensure all server changes use Refresh in Client
• Avoid long-lived stale objects

Update: it is clear to us that this is a platform problem. We do not expect this to be picked up by Mendix soon. We did find a workaround for now, which has worked for us for over a month now and thus seems safe.

Temporary fix until the issue is solved by Mendix

The problem seems to be connected to the session timeout. Increasing the SessionTimeout runtime setting seems to (completely) mitigate the problem. The Mendix standard setting is 600.000 (10 minutes). We changed it to 6.000.000 (100 minutes). We also set the EnableKeepAlive runtime setting to false, read below why.

Impact of changing the SessionTimeout

The expected impact of this change is possibly increasing the memory usage of the server. Mendix documentation notes (https://docs.mendix.com/refguide/tricky-custom-runtime-settings/#general-settings):

Increasing the session timeout can improve the user experience, especially on mobile devices. It is important to keep in mind that entities used to present data to the user or entities that are created or retrieved when a user executes a microflow are tied to that user’s session, and those entities can remain in memory for long periods of time. When a user signs out, these entities will be removed from memory, but if the user idles but does not sign out (for example, if they leave the browser tab open while executing other tasks or simply close the browser without signing out), the session timeout can act as a safeguard that prevents memory usage from being tied up by idle sessions. The first case can also be mitigated by setting the EnableKeepAlive custom setting to false. On most browsers, this setting will ensure that any idle browser tab will be affected by the session timeout as well.

We have not found any implications by putting this 'hotfix' into use.

Hopefully this helps other people, since we were lost on this problem for a long time ourselves and Mendix Support was unable to help.

It would be nice if the fix Mendix implemented in v10 was backported to v9.  We have been seeing this exact same issue for the entire time we have been on v9 and are currently on the latest 9.24.26.  We see it every single day.

I was also getting this error first time on Mendix v9.24.23 when user exporting PDF from Mendix application button click.

Root cause: it was analyzed that business is using email or html txt copy and directly pasting into Rich text widget on Mendix page. In this text, hyperlink and special characters are also coming and these are causing error when user wants to export PDF. PDF template is being used for this feature development.

com.mendix.webui.WebUIException: Exception while executing runtime operation    at com.mendix.webui.actions.client.RuntimeOperationAction.$anonfun$apply$1(RuntimeOperationAction.scala:62)Caused by: com.mendix.webui.WebUIException: Attempt to illegally add an object to the state with id '58546795156176885'    at com.mendix.webui.requesthandling.helpers.StateHandling.$anonfun$addObjectsToState$1(StateHandling.scala:133)

Solution: we educated business to paste same text in note file to make it a plain text, then copy and paste it from text file into Mendix so that unwanted styles and characters will not come into application and PDF will be exported smoothly. This is helping us as of now. 

We are experiencing the same problem after upgrading from Mendix 10.14 to 10.17. 

Hi,

I had the same issue. In my case, it was caused by java action 'commitInSeparateDatabaseTransaction'.

I was using this java action during generation PDF since commit action doesn't work in PDF document generation microflows.

If you are using the same java action, you should remove it.