Stops storing text content

[ibrokemypie]

After running for a while my clipse seems to have bugged out, now no textual clipboard entries end up in the history anymore. New image entries are still getting stored, and running clipse -p prints the text from my clipboard as expecting.

Heres how its being run if that helps narrow down the cause:

17:58:22 > systemctl --user status clipse
● clipse.service - Useful clipboard manager TUI for Unix
     Loaded: loaded (/home/noodle/.config/systemd/user/clipse.service; enabled; preset: ignored)
     Active: active (running) since Tue 2025-07-08 09:53:21 AEST; 8h ago
 Invocation: 82707dbc666a4e55a43622b70114ecf0
    Process: 4339 ExecStart=/nix/store/35yjc3r0lp5ccz8lvhaqbnqz686lhnhn-clipse-1.1.0/bin/clipse -listen (code=exited, status=0/SUCCESS)
      Tasks: 7 (limit: 18785)
     Memory: 3.4M (peak: 20.7M, swap: 1.2M, swap peak: 1.2M, zswap: 95.9K)
        CPU: 8.096s
     CGroup: /user.slice/user-1000.slice/user@1000.service/background.slice/background-graphical.slice/clipse.service
             ├─4367 wl-paste --type image/png --watch /nix/store/35yjc3r0lp5ccz8lvhaqbnqz686lhnhn-clipse-1.1.0/bin/clipse --wl-store ">/de>
             ├─4368 wl-paste --type text --watch /nix/store/35yjc3r0lp5ccz8lvhaqbnqz686lhnhn-clipse-1.1.0/bin/clipse --wl-store ">/dev/nul>
             └─5331 /nix/store/35yjc3r0lp5ccz8lvhaqbnqz686lhnhn-clipse-1.1.0/bin/clipse --wl-store ">/dev/null" "2>&1" "&"

Jul 08 09:53:21 noodlepad systemd[4124]: Starting Useful clipboard manager TUI for Unix...
Jul 08 09:53:21 noodlepad systemd[4124]: Started Useful clipboard manager TUI for Unix.
17:58:57 > systemctl --user cat clipse
# /home/noodle/.config/systemd/user/clipse.service
[Install]
WantedBy=graphical-session.target

[Service]
ExecStart=/nix/store/35yjc3r0lp5ccz8lvhaqbnqz686lhnhn-clipse-1.1.0/bin/clipse -listen
Restart=on-failure
Slice=background-graphical.slice
Type=forking

[Unit]
After=graphical-session.target
BindsTo=graphical-session.target
Description=Useful clipboard manager TUI for Unix

And heres the contents of my config.json

{
    "allowDuplicates": false,
    "historyFile": "clipboard_history.json",
    "maxHistory": 100,
    "logFile": "clipse.log",
    "themeFile": "custom_theme.json",
    "tempDir": "tmp_files",
    "keyBindings": {
        "choose": "enter",
        "clearSelected": "S",
        "down": "down",
        "end": "end",
        "filter": "/",
        "home": "home",
        "more": "?",
        "nextPage": "right",
        "prevPage": "left",
        "preview": " ",
        "quit": "q",
        "remove": "x",
        "selectDown": "ctrl+down",
        "selectSingle": "s",
        "selectUp": "ctrl+up",
        "togglePin": "p",
        "togglePinned": "tab",
        "up": "up",
        "yankFilter": "ctrl+s"
    },
    "imageDisplay": {
        "type": "sixel",
        "scaleX": 16,
        "scaleY": 16,
        "heightCut": 10
    }
}

Heres a screenshot of what clipse shows, after I had to copy those last two code blocks into the clipboard to paste in this issue (there should be an entry for each, but instead there are only entries for images)

[ibrokemypie]

After restarting the service my text copies are getting stored again.

Notably, the processes running in the service are different now, the /nix/store/35yjc3r0lp5ccz8lvhaqbnqz686lhnhn-clipse-1.1.0/bin/clipse --wl-store ">/dev/null" "2>&1" "&" present in the original status output is now missing, could be related?

11:14:03 > systemctl --user restart clipse
11:14:07 > systemctl --user status clipse
● clipse.service - Useful clipboard manager TUI for Unix
     Loaded: loaded (/home/noodle/.config/systemd/user/clipse.service; enabled; preset: ignored)
     Active: active (running) since Wed 2025-07-09 11:14:07 AEST; 21s ago
 Invocation: 2379fd47fa4344a0aee708cd337b331e
    Process: 207919 ExecStart=/nix/store/35yjc3r0lp5ccz8lvhaqbnqz686lhnhn-clipse-1.1.0/bin/clipse -listen (code=exited, status=0/SUCCESS)
      Tasks: 2 (limit: 18785)
     Memory: 2.4M (peak: 9.1M)
        CPU: 52ms
     CGroup: /user.slice/user-1000.slice/user@1000.service/background.slice/background-graphical.slice/clipse.service
             ├─207927 wl-paste --type image/png --watch /nix/store/35yjc3r0lp5ccz8lvhaqbnqz686lhnhn-clipse-1.1.0/bin/clipse --wl-store ">/dev/null" "2>&1" "&"
             └─207928 wl-paste --type text --watch /nix/store/35yjc3r0lp5ccz8lvhaqbnqz686lhnhn-clipse-1.1.0/bin/clipse --wl-store ">/dev/null" "2>&1" "&"

Jul 09 11:14:07 noodlepad systemd[4124]: Starting Useful clipboard manager TUI for Unix...
Jul 09 11:14:07 noodlepad systemd[4124]: Started Useful clipboard manager TUI for Unix.

[savedra1]

Hi @ibrokemypie

Apologies for the delay in getting back. Sounds like there was some issue with the wl-paste text watcher... Is this now working ok?

Thanks

[DragonDuck24]

I am also having this issue, however for me it seems to occur when I copy some large text content only (a 4000 line json file). As soon as I make the copy, the TUI stops showing any new history until i clipse -kill, and restart with clipse -listen. clipse -p does show the correct content even after the TUI stops updating.
One thing of note for me is I was perfectly able to copy any size content for the longest time, then it just stopped working. I didnt make any updates or config changes when it broke, it just broke and has been having issues ever since.

[MrHappy]

I have the same issue, is there any news on this?

[savedra1]

@MrHappy @DragonDuck24

Have you checked the $XDG_CONFIG/clipse.log file for any errors?

Could you not use a WM like Hyprland to manage the listener service?

The wl-clipboard listener that clipse uses for wayland might have it's own error log somewhere too.

There have been several misc updates and bug fixes since the last "official" release, so it could be worth rebuilding manually from the latest commit to see if that helps. If doing this please use the "wayland" tag, e.g. go build -tags wayland -o clipse, as a new auto-paste feature requires this.

[DragonDuck24]

@savedra1
My clipse.log:

2025/07/20 20:29:49 logger.go:19: ERROR: EOF
2025/07/20 22:00:42 logger.go:19: ERROR: unexpected EOF

It only contains those two lines and nothing recent. Those errors are not the problem.

I do use Hyprland, and currently start Clipse on boot with exec-once = clipse -listen &

wl-clipboard doesn't seem to have a log file anywhere as far as I can tell.

The issue still persists on a build from the main branch.

For more context, a 117KB file breaks it, a 90KB file does not. Not sure exactly where the limit is. It also seems like it sometimes fixes itself, but I cannot seem to identify how or when that occurs.

Let me know if any more info is needed

[savedra1]

@DragonDuck24 Thanks for the info. If you stop the clipse listener with clipse -kill and just run wl-clipboard in it's own session/window, something like: wl-paste --type "text" --watch cat and then try copying differnet contents, that will tell us if your wl-clipboard install is the issue, or clipse itself. If it's an issue with storing the large text (possible memory issue?) you could test with wl-paste --type "text" --watch tee filename.txt

I'll see if I can reproduce when I get a chance.

[DragonDuck24]

@savedra1 Using both wl-paste commands you provided, it only copies the first so much of the the text. Of note, it copies exactly 65535 characters. Well I think that's the issue. Something in wl-paste uses a 16-bit integer, and has issues with anything larger.

wl-paste, however, continues to track clipboard copies after attempting to copy long text strings. Even if the cause of the problem is outside of clipse, perhaps it could be investigated to continue listening to new copies instead of freezing or doing whatever it does now.

I'll look into making a report to wl-clipboard.

[DragonDuck24]

I think this is a Hyprland specific issue, and I think this discussion is relevant. I will look more in depth to if this only occurs with XWayland later.
@ibrokemypie @MrHappy Would either of you be able to confirm if you use Hyprland?

[MrHappy]

I'm using Hyprland (on Arch).

[savedra1]

@DragonDuck24 Thank you for getting to the bottom of that one. Interestingly, I haven't been able to reproduce this on Hyprland using the same method in your wl-clipboard issue.

E.g. with wl-paste --type text --watch wc -c running, I get the following output:

cat testdata.txt | head -c 80010 | wl-copy

❯ wl-paste --type text --watch wc -c
80010

I am on Hyprland v0.52.0 and NixOs 25.05 for reference. Makes me wonder if this could have been fixed in a recent Hyprland version, or if it goes beyond the compositor and is a distribution issue between Nix/Arch etc. The joys of local development 😄