The great thing about Redux Devtools is it adheres well to Redux's principles. The only way you should be changing the state is by dispatching an action
with whatever custom parameters you want and then let the reducer handle the state change logic. This is preferred so it adheres to the second principle (state is read-only) and the third principle of Redux which states:
Changes are made with pure functions
To specify how the state tree is transformed by actions, you write pure reducers.
So the way you would make a state change is to define a specific action that changes the piece of state you want through the reducer.
There is a very important reason for this -- this way you can verify whatever state you are trying to test is actually a possible state that your application can end up in. If you mutated bits and pieces of the state directly, it's possible your application might never reach that state.
It might seem tedious but this means that if you wanted to try and test a complex state your application could hit, you'd have to dispatch all the correct actions in order to get to that state but at least you know that is a possible state your application will run into and how your users can hit that state.