Wordpress Autoptimize occasionally losing write access?

I'd occasionally see this error message if I have CSS/JS optimization enabled on Autoptimize:

It's a brand new wordpress vhost (menu 22). The only thing I didn't turn on was installing CyberChimps Responsive Theme. I wonder if that was related?
Oh yea, I also went with KeyCDN Cache Enabler.

Sometimes the error would disappear by itself, and I could confirm through this little applet that it would indeed make cache just fine:

I could also confirm the cache would be used properly in homepage for example:

But sometimes it'd break again for no reason really. Frankly I had no idea what was going on.
At least for the time being it appears to be working, but I figure I'll ask around here anyway if anybody has a clue.

EDIT: This was actually my second attempt at making wordpress vhost (menu 22). The first one had the same issue, but the errors would pop out a lot more often.

UPDATE +1H AFTER POSTING THIS: It happened again, and lasted for roughly 2 minutes. During the whole breakdown, the whole WordPress site was inaccessible with plain text error message saying "No input file specified".

 

I believe back then I did periodically purge Autoptimize cache from Settings > Autoptimize > Save Changes and Empty Cache, mainly after adding/removing some random plugins.
I might have also occasionally used Settings > Cache Enabler > Save Changes, which claimed that doing so would also remove its cache. But I believe I used Autoptimize's ones a bit more often.

I speculate I seemed to be getting the write access error, as well as the "No input file specified" error, when either addon was still building their own cache?
Yesterday I just rebooted my server after updating kernels and a bunch of other stuff, and when I attempted to visit the WordPress vhost through my browser many minutes later (my other nginx+node and nginx+php-fpm vhosts were all already up and running properly for a couple minutes at this point), I got the same "No input file specified" error again.
It'd only work about 5 minutes afterwards, which I believe was due to that first visit being the trigger for it to start working things behind the scene? (cause unlike node that will keep on running even without traffic?)
The WordPress vhost is a private test installation, so I should indeed have been its first legit traffic after the server reboot.

Unfortunately I was already away from my PC at that time so I haven't managed to run the commands you asked right when it was broken.
As of right now, the WordPress vhost is currently working just fine, but I didn't particularly do anything, so I can only assume it's merely because it currently has proper cache.

---

Though if it helps, here are output of the commands you asked, but I ran them when the vhost was working, so I'm not sure if they'll even be relevant.

Spoiler: wp option list --search=autoptimize* --format=json | jq

Code (Text):

[
  {
    "option_name": "autoptimize_cache_clean",
    "option_value": "0"
  },
  {
    "option_name": "autoptimize_cache_nogzip",
    "option_value": "on"
  },
  {
    "option_name": "autoptimize_cdn_url",
    "option_value": ""
  },
  {
    "option_name": "autoptimize_css",
    "option_value": "on"
  },
  {
    "option_name": "autoptimize_css_aggregate",
    "option_value": "on"
  },
  {
    "option_name": "autoptimize_css_datauris",
    "option_value": ""
  },
  {
    "option_name": "autoptimize_css_defer",
    "option_value": ""
  },
  {
    "option_name": "autoptimize_css_defer_inline",
    "option_value": ""
  },
  {
    "option_name": "autoptimize_css_exclude",
    "option_value": "wp-content/cache/, wp-content/uploads/, admin-bar.min.css, dashicons.min.css"
  },
  {
    "option_name": "autoptimize_css_include_inline",
    "option_value": "on"
  },
  {
    "option_name": "autoptimize_css_inline",
    "option_value": ""
  },
  {
    "option_name": "autoptimize_css_justhead",
    "option_value": ""
  },
  {
    "option_name": "autoptimize_enable_site_config",
    "option_value": "on"
  },
  {
    "option_name": "autoptimize_html",
    "option_value": "on"
  },
  {
    "option_name": "autoptimize_html_keepcomments",
    "option_value": "on"
  },
  {
    "option_name": "autoptimize_imgopt_launched",
    "option_value": "on"
  },
  {
    "option_name": "autoptimize_imgopt_settings",
    "option_value": "a:3:{s:33:\"autoptimize_imgopt_select_field_2\";s:1:\"2\";s:35:\"autoptimize_imgopt_checkbox_field_3\";s:1:\"1\";s:31:\"autoptimize_imgopt_text_field_5\";s:0:\"\";}"
  },
  {
    "option_name": "autoptimize_js",
    "option_value": "on"
  },
  {
    "option_name": "autoptimize_js_aggregate",
    "option_value": "on"
  },
  {
    "option_name": "autoptimize_js_exclude",
    "option_value": "wp-includes/js/dist/, wp-includes/js/tinymce/, js/jquery/jquery.js"
  },
  {
    "option_name": "autoptimize_js_forcehead",
    "option_value": ""
  },
  {
    "option_name": "autoptimize_js_include_inline",
    "option_value": ""
  },
  {
    "option_name": "autoptimize_js_justhead",
    "option_value": ""
  },
  {
    "option_name": "autoptimize_js_trycatch",
    "option_value": ""
  },
  {
    "option_name": "autoptimize_minify_excluded",
    "option_value": "on"
  },
  {
    "option_name": "autoptimize_optimize_checkout",
    "option_value": ""
  },
  {
    "option_name": "autoptimize_optimize_logged",
    "option_value": "on"
  },
  {
    "option_name": "autoptimize_service_availablity",
    "option_value": "a:2:{s:12:\"extra_imgopt\";a:3:{s:6:\"status\";s:2:\"up\";s:5:\"hosts\";a:1:{i:1;s:26:\"https://cdn.shortpixel.ai/\";}s:16:\"launch-threshold\";s:4:\"4096\";}s:7:\"critcss\";a:2:{s:6:\"status\";s:2:\"up\";s:5:\"hosts\";a:1:{i:1;s:24:\"https://criticalcss.com/\";}}}"
  },
  {
    "option_name": "autoptimize_version",
    "option_value": "2.6.2"
  }
]

Spoiler: ls -lah /home/nginx/domains/my.domain/public/wp-content/cache

Code (Text):

total 20K
drwxrws--- 4 nginx nginx 4.0K Apr 29 18:57 .
drwxr-s--- 8 nginx nginx 4.0K Apr 29 18:53 ..
drwxrws--- 4 nginx nginx 4.0K Apr 29 16:03 autoptimize
-rw-r--r-- 1 nginx nginx   47 Apr 29 17:17 cache-enabler-advcache-my.domain.json
-rw-r--r-- 1 nginx nginx    0 Apr 24 16:05 index.html
drwxr-sr-x 2 nginx nginx 4.0K Apr 29 03:55 tmp

Spoiler: wp option get cache-enabler --format=json | jq

Code (Text):

{
  "expires": 6,
  "new_post": 0,
  "new_comment": 0,
  "webp": 0,
  "clear_on_upgrade": 1,
  "compress": 0,
  "excl_ids": "",
  "excl_regexp": "",
  "excl_cookies": "",
  "incl_attributes": "",
  "minify_html": 0
}

Oh yeah, disclaimer: I had previously uninstalled both Autoptimize and Cache Enabler. I only reinstalled them again yesterday, specifically a couple hours before I did the server reboot I mentioned above.

 

I think I finally figured it out.
Somehow, fastcgi_param PHP_ADMIN_VALUE from a custom php.conf I made for a PrivateBin installation leaked to the WordPress vhost.
I don't really get it, but apparently subsequent fastcgi_param is supposed to inherit values from previous ones if unset, EVEN IF they were from a different server block altogether (?).
Anyway yeah.. The one from my PrivateBin installation forced open_basedir of the WordPress vhost to the PrivateBin vhost directory instead, which obviously was NOT where the WordPress vhost was.
In the end I fixed it by uncommenting the one from php-wpsc.conf. I also uncommented the ones on the default php.conf and other custom php.conf for good measures.