Inconsistent behavior and silent failures in officecli (v1.0.110) - Commands returning Exit Code 1 with no output

[QLKT]

**Description:
I am experiencing significant instability when using officecli (version 1.0.110) on a Windows environment. The tool frequently fails to execute basic commands, especially file creation, and often returns Exit code: 1 without any output in STDOUT or STDERR.

**Environment:
OS: Windows 11
officecli Version: 1.0.110
Shell: PowerShell / CMD

**Problem Summary:
Silent Failures: Running basic commands like officecli create or officecli create_word often results in Exit code: 1 with completely empty STDOUT and STDERR. This suggests a process hang, a silent crash, or a permission issue that isn't being reported properly.
Inconsistent Command Mapping: The built-in skills/wrappers for officecli seem to be calling create_word, but the CLI tool expects create or new. This leads to failures in AI-integrated environments.
Resident Process Issues: When attempting the "Resident" workflow (open -> set/add -> save -> close), the open command frequently times out or fails to initialize the session correctly, making it impossible to perform multi-step edits.

**Steps to Reproduce:
Install officecli (v1.0.110).
Run officecli --version (Confirms installation).
I am running officecli external mode with LmStudio, model Gemma4 12b Qat.
Attempt to create a file via shell: officecli create "C:\path\to\test.docx".
Result: Frequently returns Exit code 1 with no output.
Attempt to create a file via an AI Skill wrapper.
Result: Fails because the skill calls create_word instead of create.
Attempt the Resident workflow: officecli open followed by officecli set .
Result: open command often times out or fails to establish the connection.

**Here are the thingking process "The user wants to fix the officecli tool so it works properly for Word, Excel, and PowerPoint.

Based on my previous steps:

1. The user has officecli version 1.0.110 installed.
2. The officecli --help output shows it supports commands like create, open, set, save, close, merge, etc.
3. The officecli create command works (Exit code 0), but officecli open seems to time out or fail when chained, or when used with set.
4. The Skill tool officecli is failing because it's using incorrect command names (like create_word instead of create).

To fix this for the user, I should:

1. Stop using the officecli Skill entirely because it's mapped incorrectly for this version.
2. Instead, I should provide a way to use officecli via ExecCommand directly.
3. Since the user wants me to "fix it to run well", and I cannot rewrite the Skill tool's internal logic, the "fix" is for me (the AI) to know how to correctly call the CLI using ExecCommand with the correct syntax.

The user wants the CLI to run well for PPT, Word, and Excel.
The officecli documentation provided in the --help output gives the correct schema.

• To create a doc: officecli create <path>
• To write content: officecli open <path> -> officecli set <path> <node_path> <content> -> officecli save <path> -> officecli close <path>
• For Excel: officecli import <file> <parent-path> <source-file> for CSV/TSV.

Wait, I see a merge command: officecli merge <template> <output>. This might be a more stable way to create files with content.
And a batch command: officecli batch <file>.

Actually, the most reliable way to "fix" this for the user is to establish a standard procedure I will follow.

I will tell the user:

1. I have identified that the officecli Skill is using the wrong commands for your version.
2. I will now bypass that Skill and use the direct officecli commands via the shell, which I have confirmed works for creating files.
3. I will use the correct "Open -> Set -> Save -> Close" sequence to ensure content is actually written.

Let's try the open command again, but alone, to see if it actually works or if it's always timing out. If it times out, the issue might be that the Resident process is being blocked by the OS.

One more thing: I noticed the open command says "Start a resident process". This usually means it starts a background worker.

I'll try open on a file that I just created."

**Expected Behavior:
Commands should return Exit code: 0 upon successful execution.
If an error occurs, the tool should provide descriptive messages in STDERR.
The open command should reliably initialize the document in memory for subsequent commands.

**Additional Context:
I have already tried running the terminal as Administrator.
I have disabled Antivirus software, but the issue persists.
The problem appears to be a low-level execution issue where the child process launched by officecli is either being killed immediately or is failing to communicate back to the parent shell.

[goworm]

Hi @QLKT, thanks for the detailed report. A couple of clarifications — most of this looks like a client-side wiring issue rather than an officecli bug:

1. create_word is not an officecli command.
   officecli has never exposed a create_word / create_excel verb. The actual command is just create, with the document type inferred from the extension:

officecli create test.docx
officecli create data.xlsx
officecli create slides.pptx
So whatever is emitting create_word is the wrapper/skill layer (or the model hallucinating a tool name), not the CLI. That alone explains the Exit code 1: officecli rejects the unknown command. (Error text goes to stderr — if you're only capturing stdout in PowerShell it'll look like "no output". Try officecli create test.docx 2>&1 and check $LASTEXITCODE.)

2. Install officecli's MCP server into LM Studio directly:

officecli mcp lms
Then restart LM Studio to activate it, and verify with:

officecli mcp list
This is the key fix: once the model talks to officecli through its own MCP server, the tool names and arguments come from officecli's tool schema, so it can no longer invent names like create_word — only the real tools are callable. (The plugin is written to ~/.cache/lm-studio/extensions/plugins/mcp/officecli/.)

3. Please also upgrade.
   You're on 1.0.110; the latest is 1.0.113, which includes several MCP-registration and resident-session fixes.

If you still hit a silent Exit code 1 after wiring through officecli mcp lms, please paste the exact command, full stderr, and $LASTEXITCODE and we'll dig in.

[QLKT]

Hi @QLKT, thanks for the detailed report. A couple of clarifications — most of this looks like a client-side wiring issue rather than an officecli bug:

1. create_word is not an officecli command.
   officecli has never exposed a create_word / create_excel verb. The actual command is just create, with the document type inferred from the extension:

officecli create test.docx officecli create data.xlsx officecli create slides.pptx So whatever is emitting create_word is the wrapper/skill layer (or the model hallucinating a tool name), not the CLI. That alone explains the Exit code 1: officecli rejects the unknown command. (Error text goes to stderr — if you're only capturing stdout in PowerShell it'll look like "no output". Try officecli create test.docx 2>&1 and check $LASTEXITCODE.)

2. Install officecli's MCP server into LM Studio directly:

officecli mcp lms Then restart LM Studio to activate it, and verify with:

officecli mcp list This is the key fix: once the model talks to officecli through its own MCP server, the tool names and arguments come from officecli's tool schema, so it can no longer invent names like create_word — only the real tools are callable. (The plugin is written to ~/.cache/lm-studio/extensions/plugins/mcp/officecli/.)

3. Please also upgrade.
   You're on 1.0.110; the latest is 1.0.113, which includes several MCP-registration and resident-session fixes.

If you still hit a silent Exit code 1 after wiring through officecli mcp lms, please paste the exact command, full stderr, and $LASTEXITCODE and we'll dig in.

Thank you for your guidance! I'll try to update to 1.0.113 version of officecli and also try the mcp. I forgot to tell that this issue is actually happened when I tried a test prompt in AionUI v 2.1.17 because of many times failures trying to create a document, then I ask to test if the officecli worked with docx files. If it's not related, I'll move to AIonUI repo to ask for further help, many thanks again
PS: I've just updated both officecli to 1.0.113 version and AionUI v 2.1.19 but still had the same issues on AionUI, please help me

[goworm]

Thanks for the screenshots — they clarify a lot. Quick correction to my earlier reply: officecli-docx is a real officecli skill (it ships with officecli and AionUi injects it), so the model was actually asking for the right thing. The problem is that AionUi's Skill tool returned Skill 'officecli-docx' not found — i.e. the skill wasn't available/injected in that session. So this is happening in the AionUi ↔ model layer, not in the officecli binary itself.

The most likely factor is the model: Gemma-4-12b-QAT is a small local model, and small models often struggle to drive tools/skills reliably even when they're correctly registered.

Two quick things to try:

1. Run officecli --version once to confirm the binary responds (rules out a broken install).
2. In AionUi, switch to opencode (it has free models available) and just ask it to generate a document — see if it works. Alternatively, you can use Codex or Claude Code, which also drive the skills reliably.

If it works under a more capable model, that points to the local Gemma model being the bottleneck rather than officecli, and any remaining tuning would be on the AionUi side.

Let us know how it goes!

[QLKT]

Thanks for the screenshots — they clarify a lot. Quick correction to my earlier reply: officecli-docx is a real officecli skill (it ships with officecli and AionUi injects it), so the model was actually asking for the right thing. The problem is that AionUi's Skill tool returned Skill 'officecli-docx' not found — i.e. the skill wasn't available/injected in that session. So this is happening in the AionUi ↔ model layer, not in the officecli binary itself.

The most likely factor is the model: Gemma-4-12b-QAT is a small local model, and small models often struggle to drive tools/skills reliably even when they're correctly registered.

Two quick things to try:

1. Run officecli --version once to confirm the binary responds (rules out a broken install).
2. In AionUi, switch to opencode (it has free models available) and just ask it to generate a document — see if it works. Alternatively, you can use Codex or Claude Code, which also drive the skills reliably.

If it works under a more capable model, that points to the local Gemma model being the bottleneck rather than officecli, and any remaining tuning would be on the AionUi side.

Let us know how it goes!

Thanks again for your guidance,
Here are the status:

• Run officecli --version : get '1.0.113'
• I've tried Opencode to create a pptx on desktop, it worked (opencode zen mode, with nemotron 3 ultra free) but it seemed using officecli mcp rather than using officecli-pptx

The issue is officecli with Gemma-4-12b-QAT still can create files for docx and pptx as I tested, but when trying to use creators in AIonUI it stated that couldn't find the skills.
There's one thing I've been questioning is the path to skills folder in setting of AionUI is "C:\Users\THAI LINH\AppData\Roaming\AionUi\aionui\skills" while the actual path is "C:\Users\THAI LINH\AppData\Roaming\AionUi\aionui\builtin-skills", is it affected the calling of skills during processes?