Stuck on 'Running' for 3 Days After Morning Update

📝 Originally published (in Japanese) at forge.workstyle.tech.

September 29, 09:52 AM.
The scheduled task for the Claude desktop app was displayed as "Running."
The logs showed four consecutive calls to export records from the page's database.
There was no sign of anything moving beyond that point.

It didn't look like it had stopped. On the surface, it was still in progress.

This process was responsible for the final step of the daily morning board update: exporting records from the page's database, regenerating the HTML, and re-publishing the page. The execution on September 29 had stalled at that very first export.

I was using the desktop app session remotely, so I couldn't reach the authorization screen. Even if there was a process waiting for my approval on the other side of the screen, I couldn't move forward without clicking "Allow."

In the meantime, the screen continued to display "Running."

Morning Updates Were Divided into Three Stages

I view the delivery numbers and work records on three pages: the dashboard, post board, and comment board. All of these are Artifacts published by Claude, and the records are stored in the page's DB.

The morning updates were not a single process.

At 09:30, launchd aggregates the viewing count. At 09:40, another launchd process rebuilds the HTML. Finally, from 09:45, Claude writes records from the page's DB, rebuilds the HTML, and re-publishes two pages.

The mid-stage processes can be run with a local script. In fact, the morning script collects comments and rebuilds the dashboard and comment board HTML from local data. Even if comment collection fails, it continues processing with the previous content. To prepare for page updates, local HTML is created in advance.

However, the final stage requires tools to read and write the page's DB and publish Artifacts. This part could not be executed with scripts alone.

It had been confirmed that the headless claude -p does not have Artifact-related tools. Therefore, I decided to assign the final task to the "Periodic Task" in the Claude desktop application. The configuration was to proceed with data output and publication at a fixed time every morning.

September 29: The output stopped after the start

The execution log from September 29 at 09:52 showed four calls regarding the initial DB write. It stopped there. The task remained displayed as "Running."

In reality, it was waiting for approval.

If the previous execution doesn't finish, the next scheduled execution will not start. Neither the executions for September 30 nor October 1 began. Not only had my morning routine grind to a halt, but the unfinished execution remained stuck, blocking the tasks for the following day as well.

"The scheduled tasks are backed up."

That was my reaction. On the screen, it looks like it's moving. However, I can't reach the screen to complete the approval. With just a "Running" status, you can't even tell how far along the process has progressed. The furthest I saw was the point where those four calls were made.

I had registered this process assuming it would complete automatically when the time came. In reality, it required human approval after the scheduled time had passed.

Adding Permissions Didn’t Resolve the Hang

My first thought was that adding the necessary tools and commands to the permission settings might allow the process to proceed. I attempted to append the required entries to permissions.allow in ~/.claude/settings.json.

However, the automated safety check halted the operation. It flagged the action as "modifying my own permission settings."

Since the automated mode wouldn’t let me proceed, I switched to manual mode, approved the change, and added the permissions to the settings. I then checked if the scheduled task would run successfully.

The result remained unchanged.

The next execution also halted at the first database export. Even after adding permissions to the settings file, the scheduled task still required approval at the same point.

Later, I discovered that scheduled tasks seem to use approvals remembered on a per-task basis. At least in this execution, the permissions added to the settings file had no effect. Simply fixing the settings didn’t allow the next execution to proceed automatically.

Around the same time, the server for the automated safety checks was also unresponsive during certain periods. If the check failed to return a decision 10 times in a row, the process would halt, preventing both commands and file edits from proceeding. Even configuration changes to investigate approval issues were sometimes stopped by separate safety checks.

The scheduled task remained stuck, awaiting approval. Attempts to add permission settings were blocked by safety checks, and even after approving them, the execution still halted at the same point. The task status remained "Running."

"Maybe the terminal is more reliable"

I decided that the terminal might be the more reliable option.

In the end, I manually closed the scheduled task in the desktop app. Even though the "running" status remained, it was difficult to keep using that mechanism as is. When working remotely, I couldn't always grant permission when a prompt popped up.

I returned to my Claude Code session in the terminal and decided to run the same procedure via cron within that session. I used claude --resume <session-id> to resume the session and used Remote Control for remote operations. I registered the cron to run every morning at 09:47.

It has been working successfully since the next morning.

However, this cron is not a mechanism that runs independently. It lives only within the session. It disappears when you close the terminal. It only runs when waiting for input and automatically expires after 7 days. To keep it going, I have to re-register it.

I no longer get stuck on scheduled tasks in the desktop app. Instead, my workflow has shifted to maintaining the terminal session and re-registering it before it expires. I have confirmed that it has been working since the next morning. There are still constraints regarding using this as a long-term solution.

Current Updates and Future Plans

Next on the agenda is a proposal to move the page to Cloudflare and store records there as well. This would allow updates to be managed using only launchd and scripts, eliminating the need for Claude or Terminal. However, this plan has not been implemented yet.

Over the past three days, there have been some remaining issues with scheduled execution.

• Processes that require someone's approval will come to a halt during hours when no one is available to approve them. Even when they are halted, the screen may still display "executing" (実行中 (executing)).
• To incorporate them into scheduled execution, they should be composed of tools that do not require approval or be run in a location where necessary approvals can be obtained in advance.
• Simply registering a morning time slot does not guarantee that the subsequent processes will complete successfully.