Newly invoked Treasure Chest sometimes refuses to send a Pirate URI to the running instance of Treasure Chest

[warelock2]

Describe the bug
Newly invoked Treasure Chest sometimes refuses to send a Pirate URI to the running instance of Treasure Chest

To Reproduce
Steps to reproduce the behavior:

1. Click on a Pirate URI link in a web page
2. See a second instance of Treasure chest be spawned, displaying a data directory lock error of Cannot obtain a lock on data directory /home/USERNAME/.komodo/PIRATE. Pirate is probably already running.

Expected behavior
If Treasure Chest GUI is locked, see a GUI unlock password prompt. If already unlocked, see the currently running Treasure Chest instance open the "Z-Send" tab, with the form auto-filled out with the details of the Pirate URI link you clicked on in the web page.

Screenshots

Desktop

• OS: Ubuntu Linux v22.04 Desktop
• Browser: Firefox for Linux
• Version: 126.0.2 (64-bit)
• Affected Treasure Chest app: Treasure Chest v5.8.2 (this issue also showed up on v5.8.1)

Additional context
The improper behavior can be invoked by using any of several methods:

• Clicking on a Pirate URI link in a web browser
• Using the following Linux commands: xdg-open "insert Pirate URI here" or pirate-qt "insert Pirate URI here"

Workaround

Restart the currently running instance of Treasure Chest

Additional comments

As the improper behavior can be invoked by several methods, yet is resolved by simply restarting Treasure Chest alone, this suggests an issue with Treasure Chest itself. This issue shows up sporadically, so I'm not certain what causes it. Interacting with Treasure Chest before restarting it doesn't help.