theSquashSH

Could you please open the Accessibility preferences, remove Alfred using the minus symbol, then re-add Alfred to the Accessibility list? Based on what you're describing, it seems that macOS has forgotten the permissions, so re-setting them should resolve that.
 
Let me know how you get on
 
Cheers,
Vero

+1 I'd be willing to pay >another $30 on top of my existing Legendary license for 
unlimited clipboard history, and I'd fully accept any CPU/Memory hit necessary to get it.
 
I use Clipboard History as a general buffer for everything in my life, 
and losing everything beyond 3 months is a frequent source of headache.  
Here's a small sample of a few recent things I've lost due to history expiring:
 
flight confirmation details commit summaries with commit ids (detached commits that are hard to find due to deleted branches) important UUIDs ssh public keys many many many file paths (lots of obscure config file paths that I never bother to remember) entire config files  blog post drafts comments on social media form fields on websites  
It's always stuff that I don't realize at the time would be important later
so it would be pointless to try and use snippets for most of these.
 
Having a massive index of every meaningful string that's passed through my 
brain is incredibly useful.  If needed you could hide "6 months" "12 months" and "unlimited" behind an 
"Advanced settings" pane and display a big warning about potential performance 
downsides.
 
For now I just periodically back up `~/Library/Application\ Support/Alfred/Databases/clipboard.alfdb` 
to a separate folder, and merge the rows in it with a main database.  This at 
least allows me to query further back by querying the merged database directly.
 Maybe I'll build a workflow to do that if I have time, but no promises.
 
I've created a script that handles the backup of the db, merging it with an
infinite-history sqlite db in my home folder, and searching functionality.
 
/* Delete any items that are the same in both databases */     DELETE FROM merged_db.clipboard         WHERE EXISTS(             SELECT 1 FROM latest_db.clipboard latest             WHERE $UNIQUE_FILTER         );     /* Insert all items from the latest_db backup  */     INSERT INTO merged_db.clipboard         SELECT * FROM latest_db.clipboard; Full source: alfred-clipboard.sh (it's a fully functional infinite-history solution for Alfred, with backup, search, exporting, etc.)

One thing I want to try is periodically overwriting the Alfred internal db with my merged one,
and translating all the older timestamps so that they're artificially set to something within the last 3 months,
that way I can accumulate infinite history without Alfred attempting to expire anything.
In theory it should work fine, I'll probably update my script to do that sometime in the next week.

One thing I cant figure out though is the format of the timestamps (e.g. `584601195`), they're not valid UNIX timestamps,
they must be offsets in seconds from some custom hardcoded date.
When I tried prepending `1` to make it something like `1584601195`, it becomes a valid
unix timestamp, but the time is ~4 months in the future! If anyone has more info on the schema, let me know.
 
I also tried hacking around the limit by changing the Alfred binary directly
but unfortunately I was only able to find the limit in the .nib file (which
is useless as it's just the GUI definition).
I'd have to properly decompile Alfred it to find the actual limit logic...
 
$ ggrep --byte-offset --only-matching --text '3 Months' \       '/Applications/Alfred 3.app/Contents/Frameworks/Alfred Framework.framework/Versions/A/Resources/AlfredFeatureClipboard.nib' 12590:3 Months
 
(Now I just have to convince the Google Chrome team to also allow storing 
browser history longer than 3 months... then the two biggest sources of 
data-loss pain in my life will be eliminated).

+1 I'd be willing to pay >another $30 on top of my existing Legendary license for 
unlimited clipboard history, and I'd fully accept any CPU/Memory hit necessary to get it.
 
I use Clipboard History as a general buffer for everything in my life, 
and losing everything beyond 3 months is a frequent source of headache.  
Here's a small sample of a few recent things I've lost due to history expiring:
 
flight confirmation details commit summaries with commit ids (detached commits that are hard to find due to deleted branches) important UUIDs ssh public keys many many many file paths (lots of obscure config file paths that I never bother to remember) entire config files  blog post drafts comments on social media form fields on websites  
It's always stuff that I don't realize at the time would be important later
so it would be pointless to try and use snippets for most of these.
 
Having a massive index of every meaningful string that's passed through my 
brain is incredibly useful.  If needed you could hide "6 months" "12 months" and "unlimited" behind an 
"Advanced settings" pane and display a big warning about potential performance 
downsides.
 
For now I just periodically back up `~/Library/Application\ Support/Alfred/Databases/clipboard.alfdb` 
to a separate folder, and merge the rows in it with a main database.  This at 
least allows me to query further back by querying the merged database directly.
 Maybe I'll build a workflow to do that if I have time, but no promises.
 
I've created a script that handles the backup of the db, merging it with an
infinite-history sqlite db in my home folder, and searching functionality.
 
/* Delete any items that are the same in both databases */     DELETE FROM merged_db.clipboard         WHERE EXISTS(             SELECT 1 FROM latest_db.clipboard latest             WHERE $UNIQUE_FILTER         );     /* Insert all items from the latest_db backup  */     INSERT INTO merged_db.clipboard         SELECT * FROM latest_db.clipboard; Full source: alfred-clipboard.sh (it's a fully functional infinite-history solution for Alfred, with backup, search, exporting, etc.)

One thing I want to try is periodically overwriting the Alfred internal db with my merged one,
and translating all the older timestamps so that they're artificially set to something within the last 3 months,
that way I can accumulate infinite history without Alfred attempting to expire anything.
In theory it should work fine, I'll probably update my script to do that sometime in the next week.

One thing I cant figure out though is the format of the timestamps (e.g. `584601195`), they're not valid UNIX timestamps,
they must be offsets in seconds from some custom hardcoded date.
When I tried prepending `1` to make it something like `1584601195`, it becomes a valid
unix timestamp, but the time is ~4 months in the future! If anyone has more info on the schema, let me know.
 
I also tried hacking around the limit by changing the Alfred binary directly
but unfortunately I was only able to find the limit in the .nib file (which
is useless as it's just the GUI definition).
I'd have to properly decompile Alfred it to find the actual limit logic...
 
$ ggrep --byte-offset --only-matching --text '3 Months' \       '/Applications/Alfred 3.app/Contents/Frameworks/Alfred Framework.framework/Versions/A/Resources/AlfredFeatureClipboard.nib' 12590:3 Months
 
(Now I just have to convince the Google Chrome team to also allow storing 
browser history longer than 3 months... then the two biggest sources of 
data-loss pain in my life will be eliminated).

Most of the workflows that deal with large amounts of text use the pasteboard to pass the text around. Stdin would be awesome, but the pasteboard is a workaround.

This is a limit imposed by UNIX, not Alfred, but the error message shown is slightly confusing, and there should be a way to overcome this issue.
 
Right now, selecting more than exactly 260527 characters on my system and using it in an Alfred workflow (with the Argument:'selection in OS X' setting) as "{query}" will throw an error.
You can see your system's bash argument character limit with:
getconf ARG_MAX Alfred should allow a way to pass the selection as stdin instead of a quoted and escaped string, otherwise there is no way around this hard limit, and Line-Counting workflows, etc. are useless for larger bodies of text.
 

^ Confusing error message when selecting too much text.
 

^ A workflow example that would trigger this.
 

echo "{query}" > .wordcount echo "Characters: "$(wc -m < .wordcount)"  Words: "$(wc -w < .wordcount)"  Lines: "$(wc -l < .wordcount) rm .wordcount