Allow tools running in the terminal to prevent the workspace from stopping due to idling

[akurinnoy]

Is your enhancement related to a problem? Please describe

From time to time, we need to run a CLI tool performing long-running tasks in a terminal. The workspace idling time can prevent such tasks from being fulfilled.
Let's take the scenario from this blog post: Spec-Driven Development in Action.
When the user runs ra-aid with a specification file, it takes quite a while to complete. And, if the idle timeout is not enough, the command will be terminated by stopping the workspace.

Describe the solution you'd like

If possible, tracking terminal activity (reading stdout, errout) and treating it as a user activity will resolve this issue.

Describe alternatives you've considered

No response

Additional context

No response

[vrubezhny]

A POC go-based app that watches for the long-running CLI apps being executed in container (the list of apps to be watched in configurable) and, if any, reports the "activity ticks" to machine-exec, thus preventing the WS from idling.

See: https://github.com/vrubezhny/che-cli-watcher

$ ./che-cli-watcher --help
CLI Watcher — Keeps your Che DevSpaces workspace active during long-running CLI tasks

This tool monitors selected long-lived CLI processes and prevents the workspace from idling
by periodically reporting activity to the DevSpaces agent.

Configuration:
  Create a YAML config file at: ~/.che-cli-watcher

Example config (~/.che-cli-watcher):

watchedCommands:
  - ra-aid
  - oc
  - odo
  - helm
  - func
checkPeriodSeconds: 60
activityReportPeriodSeconds: 60
retryPeriodSeconds: 5
retryCount: 5

Config fields:
  watchedCommands              List of command names to monitor (long-running only)
  checkPeriodSeconds           How often to check for running commands (default: 60 seconds)
  activityReportPeriodSeconds  Minimum interval between activity reports (default: 60 seconds)
  retryPeriodSeconds           Delay between retries if activity reporting fails (default: 5 seconds)
  retryCount                   Number of retry attempts for failed activity reports (default: 5)

Notes:
  - The config file is automatically reloaded when created or modified.
  - Commands like 'sleep', 'ra-aid', 'helm', or 'odo' are good examples of long-running tasks to watch.
  - Short-lived commands are ignored — this tool is optimized to avoid unnecessary workspace wakeups.

[vrubezhny]

I've proposed the PR that modifies directly the che-machine-execexecutable (so we don't need any new executable to be set up, running and communicating the "activity ticks" using REST API to the machine-exec) - See: eclipse-che/che-machine-exec#332

The watcher is user-configurable via a .noidle YAML file. No admin privileges are required.

How configuration is resolved:

The .noidle file is located by searching in the following order:

• A path specified by the CLI_WATCHER_CONFIG environment variable
• Searching upward from the current project directory toward $PROJECTS_ROOT, looking for .noidle
• Falling back to $HOME/.noidle (e.g. ~/.noidle)
• If not found, CLI Watcher waits and checks again on the next poll

Example .noidle configuration:

enabled: true
watchedCommands:
  - helm
  - odo
  - sleep
checkPeriodSeconds: 60

Where:

• enabled: Enables or disables the CLI watcher (boolean)
• watchedCommands: List of command names to monitor
• checkPeriodSeconds: Polling interval in seconds (default is 60)

Benefits:

• Works entirely in user space — no container or cluster admin config needed
• Supports live updates (file can be added, edited, or removed while running)
• Helps avoid idle timeout disconnects during long-running CLI workflows
• Allows workspace authors to tailor idle behavior to specific tools